Reviewing Devtools Prs

Reviewing DevTools Pull Requests

Extends reviewing-prs for pull requests in flutter/devtools. Follow reviewing-prs for GitHub CLI data retrieval and the strict user approval workflow.

References & Style Guidelines

Read and enforce:

• Style Guide: styleguide.md (severity tags [MUST-FIX], [CONCERN], [NIT], zero-formatting policy, copyright headers, DRY rules, magic values)
• Repository Constraints: AGENTS.md
• Code Style: STYLE.md

Common Review Patterns

• Listener & Resource Disposals:
• Ensure controller and notifier listeners use addAutoDisposeListener(...).

• Helper Widgets over Helper Methods:
• Prefer small composable Widget classes over helper methods returning Widget (_buildFoo()).

• Reuse Shared Components & Test Helpers:
• Use standard shared widgets (e.g. CenteredMessage) and test mocks (e.g. mockConnectedApp) instead of re-creating them inline.

• TODO Formatting:
• Link TODOs to a GitHub issue or LDAP: // TODO(https://github.com/flutter/devtools/issues/<issue_number>): <description>.

• Async & Unawaited Futures:
• Audit unawaited futures and suggest unawaited(...) or safeUnawaited(...) where appropriate.

• Feature Flags:
• Default feature flags to false with explicit test expectations in feature_flags_test.dart.

• Test File Structure & PR Scope:
• Place test fakes/helpers below main().
• Ask authors to revert unrelated file changes or commented-out test code.

• Constant Scoping:
• Keep single-use constants local to the component, but extract user-facing UI strings into shared constants when used across multiple places.

• Release Notes Scope (NEXT_RELEASE_NOTES.md):
• Release notes are strictly for end-user facing changes (e.g. Inspector, Memory UI/UX). Internal tools (dt / devtools_tool), CI, and refactors are NOT user-facing.
• Request removing release notes added for developer tools like dt, or suggest a * <Description>. #<PR_NUMBER> entry via adding-release-notes if a user-facing PR lacks one.