Clarify Activity as a launch-approvals feed

[nortonandreev]

Closes #1089 — AI-3061

What & why

The launcher chip labeled Activity opened the local allow/deny log for daemon launches, but the name and a seven-column table made that hard to read. It is now Launches with a short feed (outcome · vendor · kind; requester · repo · source; time). Full emails fit the wider panel; the last row has no trailing hairline. Reader, poll, and Complete rules are unchanged.

Where to look

MainWindow.axaml flyout template and ActivityViewModel.ToRow projection.

Verification

dotnet run --project test/Capacitor.App.Tests.Unit/Capacitor.App.Tests.Unit.csproj -- --treenode-filter "/*/*/ActivityViewModelTests/*"
# Passed! total: 23 failed: 0
dotnet run --project test/Capacitor.App.Tests.Unit/Capacitor.App.Tests.Unit.csproj -- --treenode-filter "/*/*/MainWindowSmokeTests/Activity_polls_only_while_open*"
# Passed! total: 1 failed: 0

Visuals

Before

After

[linear-code]

AI-3061

[qodo-code-review]

PR Summary by Qodo

Rename Activity and present launch approvals as a feed

✨ Enhancement 🧪 Tests 📝 Documentation 🕐 20-40 Minutes

AI Description

• Renames Activity to Launches and clarifies launch-approval terminology.
• Replaces the seven-column table with compact, tooltip-backed approval feed rows.
• Preserves existing log reading, polling, completion, and refresh behavior.

Diagram

graph TD
    A[("Consent log")] --> B["Activity view model"] --> C["Row projection"] --> D["Approval rows"] --> E["Launches flyout"]

Loading

High-Level Assessment

The chosen approach is appropriate: retain the established consent-log and refresh contracts, project display-ready feed fields in ActivityViewModel, and keep XAML focused on presentation. Formatting through additional XAML converters or multibindings was a possible alternative, but would make the feed composition harder to test and maintain.

Files changed (6) +716 / -88

Enhancement (2) +74 / -74

ActivityViewModel.csProject consent decisions into approval feed rows +39/-13

Project consent decisions into approval feed rows

• Reshapes ActivityRow around primary, secondary, time, and tooltip fields. ToRow now title-cases known outcomes, omits generic agent kinds and user-origin sources, and preserves full requester and repository details for hover content without changing refresh behavior.

src/Capacitor.App/ViewModels/ActivityViewModel.cs

MainWindow.axamlReplace the Activity table with the Launches feed +35/-61

Replace the Activity table with the Launches feed

• Renames the chip to Launches, adds launch-approval heading and empty-state copy, and replaces the seven-column grid with a three-line feed layout. The narrower flyout uses existing outcome colors, disables horizontal scrolling, and removes the final row separator.

src/Capacitor.App/Views/MainWindow.axaml

Tests (1) +54 / -14

ActivityViewModelTests.csCover launch-approval row projection +54/-14

Cover launch-approval row projection

• Updates mapping assertions for the feed-oriented ActivityRow shape. Adds coverage for outcome labels, omitted generic details, full email requesters, composed secondary lines, and requester/repository tooltips.

test/Capacitor.App.Tests.Unit/ActivityViewModelTests.cs

Documentation (3) +588 / -0

CHANGES.mdDocument the Launches consent-history redesign +8/-0

Document the Launches consent-history redesign

• Adds a change entry explaining that Activity represented launch consent history and is now labeled Launches. It records the move from a seven-column table to concise approval feed rows while noting unchanged persistence and refresh rules.

docs/CHANGES.md

2026-09-21-desktop-launch-approvals-feed.mdAdd the launch-approvals implementation plan +462/-0

Add the launch-approvals implementation plan

• Documents the planned view-model projection, ActivityRow reshape, flyout rewrite, testing sequence, and implementation constraints. It also identifies contracts that must remain unchanged during the redesign.

docs/superpowers/plans/2026-09-21-desktop-launch-approvals-feed.md

2026-09-21-desktop-launch-approvals-feed-design.mdSpecify the desktop launch-approvals feed +118/-0

Specify the desktop launch-approvals feed

• Defines the product rationale, naming, row hierarchy, flyout layout, requester presentation, unchanged behavioral contracts, and testing scope for the Launches experience.

docs/superpowers/specs/2026-09-21-desktop-launch-approvals-feed-design.md

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Long vendor names are clipped ✓ Resolved 🐞 Bug ≡ Correctness

Description

The primary-line TextBlock enables TextTrimming inside a horizontal StackPanel, whose
unconstrained horizontal measurement prevents the detail from being sized to the available flyout
width. When a server launch supplies a long or unknown vendor, consent records it before vendor
validation, so the fixed-width flyout clips that value while horizontal scrolling is disabled.

Code

src/Capacitor.App/Views/MainWindow.axaml[R109-111]

+                                                                            <TextBlock Text="{Binding PrimaryDetail}" FontSize="12.5"
+                                                                                       Foreground="{StaticResource KcapTextBrush}"
+                                                                                       TextTrimming="CharacterEllipsis" />

Relevance

●●● Strong

Recent UI precedents accept fixes for unconstrained horizontal layouts that can clip content in
fixed-width views.

PR-#932

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The new primary line places the detail inside a horizontal stack while the surrounding scroller
disables horizontal scrolling. Launch consent records cmd.Vendor before the subsequent
runtime-factory validation, and the log reader only requires vendor to be nonempty, so long
server-provided values can reach this display unchanged.

src/Capacitor.App/Views/MainWindow.axaml[80-84]
src/Capacitor.App/Views/MainWindow.axaml[102-116]
src/Capacitor.Cli.Daemon/Services/AgentOrchestrator.cs[2041-2058]
src/Capacitor.Cli.Daemon/Services/LaunchConsentGate.cs[80-86]
src/Capacitor.Cli.Core/LocalIpc/ConsentDecisionLog.cs[62-70]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The primary detail is measured inside a horizontal `StackPanel`, so `TextTrimming` does not receive a finite available width and long vendor values are clipped by the fixed-width flyout.

## Fix Focus Areas
- src/Capacitor.App/Views/MainWindow.axaml[104-111]

## Recommended Fix
Replace the horizontal `StackPanel` with a constrained layout such as a three-column `Grid` using `Auto,Auto,*`. Place the outcome and separator in the auto columns and `PrimaryDetail` in the star-sized column so `CharacterEllipsis` operates against the remaining width.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Commit subjects omit issue links ✓ Resolved 📘 Rule violation ⚙ Maintainability

Description

Global Constraints tells workers to create commits with no ticket id, and all six listed commit
subjects omit the trailing GitHub issue reference. Reusing this plan for subsequent work perpetuates
subjects that fail the merge-subject format instead of linking the change to its issue.

Code

docs/superpowers/plans/2026-09-21-desktop-launch-approvals-feed.md[21]

+- **Commits:** imperative subject ≤ 80 chars, no ticket id, no `Co-authored-by`. Optional body ≤ 5 lines. Stage by explicit path.

Relevance

●●● Strong

Explicit repository rule conflicts with the plan; commit-subject format corrections are
deterministic and maintainability-relevant.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

Compliance rule 2897961 requires each applicable commit subject to end with (#<digits>). The added
plan explicitly requires no ticket id, and the supplied PR metadata confirms that every resulting
commit subject lacks the required GitHub reference.

Rule 2897961: Enforce single-clause imperative commit subject with GitHub issue reference and 80-char limit
docs/superpowers/plans/2026-09-21-desktop-launch-approvals-feed.md[21-21]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The implementation plan prohibits ticket IDs in commit subjects, while the required commit format ends each subject with a GitHub issue reference; the commits in this PR consequently omit that reference.

## Fix Focus Areas
- docs/superpowers/plans/2026-09-21-desktop-launch-approvals-feed.md[21-21]

## Recommended Fix
Change the commit guidance to require a trailing `(#<GitHub issue>)` reference while continuing to prohibit Linear IDs, then rewrite the six PR commit subjects to end in `(#1089)` and retain their imperative wording.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. Feed row comment repeats its fields ✓ Resolved 📘 Rule violation ⚙ Maintainability

Description

ActivityRow's first two XML-doc lines restate that Time is a short clock and that Outcome and
PrimaryDetail contain the values already named by the record fields. Since the declaration and
projection are the authoritative shape, these duplicate descriptions add a second version that can
drift when the feed changes.

Code

src/Capacitor.App/ViewModels/ActivityViewModel.cs[R11-12]

+/// One feed row of the decision log. Time is a short local clock; TimeTip the full stamp.
+/// Outcome is Allowed/Denied; PrimaryDetail is vendor plus optional kind; SecondaryLine is

Relevance

●●● Strong

Recent precedents accept removing redundant or historical comments and retaining only durable
behavioral explanations.

PR-#666
PR-#703
PR-#1029

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

Compliance rule 2762993 disallows comments that merely restate signatures or readily apparent code.
The added XML documentation paraphrases the adjacent record fields instead of explaining why the
record has this shape or identifying a behavior-critical constraint.

Rule 2762993: Restrict comments to documenting non-obvious, behavior‑critical constraints
src/Capacitor.App/ViewModels/ActivityViewModel.cs[11-14]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The expanded `ActivityRow` XML documentation enumerates straightforward field meanings rather than limiting itself to non-obvious behavioral constraints, creating duplicate descriptions that can become stale.

## Fix Focus Areas
- src/Capacitor.App/ViewModels/ActivityViewModel.cs[11-14]

## Recommended Fix
Remove the field-by-field narration and, if documentation is retained, reduce it to one or two lines covering only the non-obvious source-omission and tooltip behavior.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Context sources

✅ Compliance rules (platform): 64 rules

✅ Cross-repo context — repo relationships

Review mode: ⚖️ Balanced: This changes runtime ViewModel projection, Avalonia UI bindings, and tests across multiple paths, creating meaningful behavioral and presentation risk but not enough independent logic density to warrant extended review.

Tip of the day

💡 Did you know, you can add REVIEW.md to your repo root and Qodo follows it on every PR

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗