feat(web-ui): surface PROOF9 gate link in execution completion banner (#469)

[frankbria]

Summary

• Adds "Verify with PROOF9" as the primary CTA in the completed state banner, linking to /proof
• Demotes "View Changes" to secondary (outline) styling
• Updates completion message: "Execution complete. Run PROOF9 gates to verify quality before shipping."
• Adds "View Blockers" as primary CTA in the blocked state banner, linking to /blockers
• Demotes "Back to Tasks" to secondary on blocked state

Closes #469

Test plan

• Complete a task execution — banner shows "Verify with PROOF9" (filled green) first, then "View Changes" (outline), then "Back to Tasks"
• "Verify with PROOF9" navigates to /proof
• Blocked state shows "View Blockers" (filled amber) and "Back to Tasks" (outline)
• "View Blockers" navigates to /blockers
• Build passes (npm run build clean)

Summary by CodeRabbit

• New Features
  • Added "Verify with PROOF9" primary action to completed executions to verify quality before shipping
  • Added "View Blockers" action when tasks are blocked for quick access to blocker details
  • Updated completion messaging to guide users to run PROOF9 verification gates
  • Improved button layout and consistent button styling across completed/blocked/failed banners

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: ff3c96d1-078f-4278-a3ab-6a63c59d2198

📥 Commits

Reviewing files that changed from the base of the PR and between 9035fe7 and 305f527.

📒 Files selected for processing (2)

• web-ui/src/app/execution/[taskId]/page.tsx
• web-ui/src/types/index.ts

✅ Files skipped from review due to trivial changes (1)

• web-ui/src/types/index.ts

🚧 Files skipped from review as they are similar to previous changes (1)

• web-ui/src/app/execution/[taskId]/page.tsx

---

Walkthrough

Adds PROOF9 navigation and blocker-view callbacks to the execution completion banner, updates completed/blocked banner layouts and text, and exposes a new CompletionBannerProps type including onViewProof and onViewBlockers.

Changes

Cohort / File(s)	Summary
Execution page / CompletionBanner web-ui/src/app/execution/[taskId]/page.tsx	Wired two new callbacks (onViewProof, onViewBlockers) into CompletionBanner; updated completed banner to show a "Verify with PROOF9" primary action and adjusted copy; blocked banner now shows a "View Blockers" CTA alongside "Back to Tasks"; replaced inline buttons with shared Button component.
Types web-ui/src/types/index.ts	Added exported CompletionBannerProps interface including status, optional duration, and four handlers: onViewProof, onViewChanges, onBackToTasks, onViewBlockers.

Sequence Diagram(s)

sequenceDiagram
    participant User
    participant ExecutionPage
    participant CompletionBanner
    participant Router

    User->>ExecutionPage: open execution page
    ExecutionPage->>CompletionBanner: render(props with callbacks)
    User->>CompletionBanner: click "Verify with PROOF9"
    CompletionBanner->>ExecutionPage: call onViewProof()
    ExecutionPage->>Router: router.push('/proof')
    Router-->>User: navigate to /proof

    alt Blocked state: "View Blockers"
      User->>CompletionBanner: click "View Blockers"
      CompletionBanner->>ExecutionPage: call onViewBlockers()
      ExecutionPage->>Router: router.push('/blockers')
      Router-->>User: navigate to /blockers
    end

Loading

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related PRs

• feat(web-ui): PROOF9 requirements list, detail, and dashboard widget (#458) #461: Adds CompletionBanner handler to navigate to /proof and updates types; directly related to implementing the PROOF9 navigation.

Poem

🐰 Hopping through lines of code so spry,
I added a gate that points to the sky.
"Verify with PROOF9" now leads the way,
See blockers, run checks, then ship with sway —
Clever carrots of quality, hop hooray! 🥕

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'feat(web-ui): surface PROOF9 gate link in execution completion banner (#469)' clearly and accurately describes the main change in the pull request—adding a PROOF9 gate link to the completion banner.
Linked Issues check	✅ Passed	The pull request successfully implements all coding requirements from issue #469: adds 'Verify with PROOF9' button linking to /proof, positions it prominently, updates completion text, and adds 'View Blockers' to blocked state.
Out of Scope Changes check	✅ Passed	All changes are directly related to the linked issue #469 objectives. The modifications to CompletionBanner component, new CompletionBannerProps type, and Button component replacements all align with surfacing PROOF9 gates.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

📋 Issue Planner

Built with CodeRabbit's Coding Plans for faster development and fewer bugs.

View plan used: #469

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/issue-469-proof9-completion-banner

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[claude]

Review: feat(web-ui): surface PROOF9 gate link in execution completion banner (#469)

This is a clean, focused change. The implementation is consistent with the existing code style and TypeScript prop types are properly updated. Both target routes (/proof and /blockers) confirmed to exist in the repo.

One UX concern worth addressing

The blocked state banner currently reads:

"Execution blocked — a blocker was raised. Answer it in the event stream below to continue."

But the new primary CTA ("View Blockers") navigates away from the page to /blockers. This contradicts the inline instruction — if the user should answer the blocker in the event stream on this page, making the primary action navigate elsewhere works against that.

Options to consider:

• Update the copy to match the new action: e.g. "Manage it on the Blockers page." instead of "Answer it in the event stream below"
• Or keep "Back to Tasks" as primary and add "View Blockers" as secondary (outline) — so the primary action isn't pulling users away from what the text told them to do

The completed state change is solid — promoting "Verify with PROOF9" as the primary CTA cleanly reinforces the Think → Build → Prove → Ship pipeline, and the message update ("Run PROOF9 gates to verify quality before shipping") gives good context.

Minor

No automated tests cover the new props/button rendering. Since CompletionBanner is a file-local component, a quick render test with the new props would help catch future regressions — though I recognize the legacy web-ui has a lower test bar.

[coderabbitai]

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@web-ui/src/app/execution/`[taskId]/page.tsx:
- Around line 167-173: Extract the inline prop type for CompletionBanner (the
object with status, duration, onViewProof, onViewChanges, onBackToTasks,
onViewBlockers) into the central types index as a named exported type or
interface (e.g., CompletionBannerProps), export it from that types module, then
import and use CompletionBannerProps in the component signature instead of the
inline type; update any references to use the new type name and ensure
exports/imports are correctly added.
- Around line 185-193: Replace the raw <button> elements used for the CTAs with
the Shadcn Button component using the Nova gray scheme: locate the elements that
reference onViewProof and onViewChanges (and the similar buttons around the
232-240 area) and swap them to use the Button component with appropriate
variant/size props (e.g., variant="ghost"/"secondary" or the Nova gray preset)
instead of hardcoded Tailwind color classes, and move the onClick handlers to
the Button props so styling is driven by Shadcn UI rather than inline className
strings.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 066de6b0-0bcf-480e-a0c3-8d9d750b17eb

📥 Commits

Reviewing files that changed from the base of the PR and between e673154 and 9035fe7.

📒 Files selected for processing (1)

• web-ui/src/app/execution/[taskId]/page.tsx

[claude]

Follow-up Review

CodeRabbit's two actionable items from the previous round are resolved — CompletionBannerProps is now in types/index.ts and all raw <button> elements are replaced with the Shadcn <Button> component. Good.

Still unaddressed from my earlier review:

Blocked state copy/CTA contradiction — the copy still reads:

"Execution blocked — a blocker was raised. Answer it in the event stream below to continue."

But the primary CTA is now "View Blockers" which navigates away to /blockers. The text tells the user to act on this page while the button takes them somewhere else. This is confusing UX. Either:

• Update the copy: e.g. "Execution blocked — a blocker was raised. Manage it on the Blockers page."
• Or flip the button priority: "Back to Tasks" as primary, "View Blockers" as secondary — so the primary action doesn't contradict the instruction.

No tests added — the new props (onViewProof, onViewBlockers) and the button layout changes in all three states still have no render test coverage. This is still a gap worth filling.

New minor observation:

CompletionBannerProps requires all four handlers regardless of which status is active. onViewProof is only meaningful when status === 'completed' and onViewBlockers only when status === 'blocked'. Callers have to supply all four even when some are unreachable. Making the state-specific ones optional (onViewProof?: () => void, onViewBlockers?: () => void) would give a more precise API and let TypeScript enforce what's actually needed per state — though this is low priority given the component is only used in one place right now.