chrome-devtools-frontend 1.0.1716465 → 1.0.1717709

package/.agents/skills/devtools-model-management/SKILL.md

@@ -9,7 +9,7 @@ This guide outlines the standard procedure for creating a new model or migrating
 
 ## 0. Preparation (Before you start)
 *   **Baseline:** Run existing tests for the code you are moving to ensure they pass *before* you touch anything.
-    *   `npm run test -- front_end/<old_location>`
+    *   `./dt test front_end/<old_location>`
 *   **Impact Analysis:** Search for usages of the class/file to understand the scope of refactoring.
     *   `grep -r "ClassName" front_end/`
 
@@ -44,10 +44,10 @@ The build system does not auto-detect new modules. You must manually register th
 
 ## 5. Verification Checklist
 1.  **Build:** `autoninja -C out/Default` (Ensures BUILD.gn and GRD files are correct).
-2.  **Lint:** `npm run lint` (Checks style and formatting).
+2.  **Lint:** `./dt lint` (Checks style and formatting).
 3.  **Test:**
-    *   `npm run test -- front_end/models/<model_name>` (New tests).
-    *   `npm run test -- front_end/<old_location>` (Regression check for previous owner).
+    *   `./dt test front_end/models/<model_name>` (New tests).
+    *   `./dt test front_end/<old_location>` (Regression check for previous owner).
 
 ## Common Pitfalls
 *   **Circular Dependencies:** Occur when internal files import from the directory's own barrel file.

package/.agents/skills/devtools-setting-migration/SKILL.md

@@ -144,7 +144,7 @@ const setting = Common.Settings.Settings.instance().resolve(preserveConsoleLogSe
 
 ### Step 6: Verify Changes
 1. Run `autoninja -C out/Default` to check GN build.
-2. Run `npm run lint` to check style and formatting rules.
+2. Run `./dt lint` to check style and formatting rules.
 3. Run relevant unit tests for the modified module.
 
 ---

package/.agents/skills/devtools-testing-guidance/SKILL.md

@@ -37,7 +37,8 @@ Use API tests for integration tests that verify business logic requiring more co
   - Tests that require extensive CDP mock setup.
   - Verifying the "foundational layer" of DevTools models against a real browser/web page.
 - **Location:** Defined in `front_end/` with `.test.api.ts` extension (e.g. `Universe.test.api.ts`).
-- **BUILD.gn**: test file should be added to `devtools_api_test_module("api_tests")` target in the corresponding `BUILD.gn` file.
+- **Test functions:** import `describe`, `it` and `setup` from `test/api/mocha-interface.ts`. They are not available as globals.
+- **BUILD.gn**: test file should be added to `devtools_api_test_module("api_tests")` target in the corresponding `BUILD.gn` file, which needs `test/api` in its `ts_deps`.
 
 ---
 
@@ -49,4 +50,5 @@ Use E2E tests to verify real end-to-end user stories and user journeys.
   - Verifying full user journeys across DevTools panels and drawers.
   - Complex UI behaviors that require extensive user interaction setup and benefit from a complete DevTools frontend page connected to an inspected target page over CDP.
 - **Location:** Defined in `test/e2e/` (e.g. `test/e2e/console/console-log.test.ts`).
-- **BUILD.gn**: test file should be added to `ts_e2e_library(ts_e2e_library)` target in the corresponding `BUILD.gn` file. And `node_ts_library` in `test/e2e/BUILD.gn` for its dependencies.
+- **Test functions:** import `describe`, `it` and `setup` from `test/e2e/conductor/mocha-interface.ts` (e.g. `import {describe, it} from '../conductor/mocha-interface.js';`). They are not available as globals.
+- **BUILD.gn**: test file should be added to the `node_ts_library` target in the corresponding `BUILD.gn` file, which needs `"../conductor:implementation"` in its `ts_deps`. And `node_ts_library` in `test/e2e/BUILD.gn` for its dependencies.

package/.agents/skills/devtools-verification/SKILL.md

@@ -1,15 +1,19 @@
 ---
 name: devtools-verification
-description: "MANDATORY: Activate this skill ANY TIME you need to build the project, run tests, or verify code health in DevTools. You MUST use this skill before executing commands like npm test, npm run build, autoninja, or linters, as it contains critical, repository-specific instructions on how to correctly format these commands, filter test runs, and interpret failures."
+description: "MANDATORY: Activate this skill ANY TIME you need to build the project, run tests, or verify code health in DevTools. You MUST use this skill before executing commands like ./dt test, ./dt build, autoninja, or linters (never run these through npm or npx), as it contains critical, repository-specific instructions on how to correctly format these commands, filter test runs, and interpret failures."
 ---
 
 # Instructions on how to verify your changes
 
+## Running scripts
+
+Run the scripts from the root `package.json` (`test`, `lint`, `build`, `start`, and so on) with `./dt <script> [args]` from the repository root (on Windows: `.\dt <script> [args]`). Don't use `npm run`, `npm test`, or `npx` for them. Run `./dt` without arguments to list the available scripts. Arguments after the script name are passed to the script as is, so don't add a `--` separator.
+
 ## Testing
 
-- To test a file, you can run `npm run test -- <FILEPATH>` where `FILEPATH` is a path to a `*.test.ts` file, relative to the working directory.
+- To test a file, you can run `./dt test <FILEPATH>` where `FILEPATH` is a path to a `*.test.ts` file, relative to the working directory.
 - Test files are usually defined alongside their implementation. So if you are working on `front_end/panels/timeline/TimelinePanel.ts`, you would expect the test file to be defined in `front_end/panels/timeline/TimelinePanel.test.ts`.
-- You can also test an entire directory. For example, `npm run test -- front_end/models/trace` will run all tests in that directory.
+- You can also test an entire directory. For example, `./dt test front_end/models/trace` will run all tests in that directory.
 
 ## Building & compiling
 
@@ -17,8 +21,8 @@ description: "MANDATORY: Activate this skill ANY TIME you need to build the proj
 
 ## Linting
 
-- `npm run lint` will execute ESLint and StyleLint. It will report any violations and automatically fix them where possible.
-- To run the linter on a specific file or directory, you can run `npm run lint -- <PATH>` where `PATH` is a path to a file or directory. This will also automatically fix violations where possible.
+- `./dt lint` will execute ESLint and StyleLint. It will report any violations and automatically fix them where possible.
+- To run the linter on a specific file or directory, you can run `./dt lint <PATH>` where `PATH` is a path to a file or directory. This will also automatically fix violations where possible.
 
 ## Fetching Tryjob Results, Failure Logs, & Screenshot Goldens
 

package/.agents/skills/fix-tests/SKILL.md

@@ -22,7 +22,7 @@ First, create and start two sub-agents simultaneously. One called 'local-repro'
 
 ### Local reproduction (local-repro)
 
-- Use command: `npm run test -- --repeat=<count> path/to/foo.test.ts:exact_test_id` to locally run the tests repeatedly. Both E2E and unit tests support this. Use the exact test ID printed in the test runner output (usually the suite and test names with spaces replaced by underscores). Do not use `--grep` or a `bash` script with a `for` loop.
+- Use command: `./dt test --repeat=<count> path/to/foo.test.ts:exact_test_id` to locally run the tests repeatedly. Both E2E and unit tests support this. Use the exact test ID printed in the test runner output (usually the suite and test names with spaces replaced by underscores). Do not use `--grep` or a `bash` script with a `for` loop.
 - First run the test three times to note how long the test runs (on average).
 - Then run the test continuously for 4 minutes, while noting any failures and failure rates. If the failure rate is still 0% after that, assume the problem does not reproduce locally.
 - After the local test run completes, then show the results in a table. For example:

package/.agents/skills/foundation-test-migration/SKILL.md

@@ -162,10 +162,10 @@ Foundation tests must pass in both Node.js and Browser runtimes.
 
 ### Run in Node.js
 ```bash
-npm test -- front_end/core/sdk/NetworkManager.test.ts --node-unit-tests
+./dt test front_end/core/sdk/NetworkManager.test.ts --node-unit-tests
 ```
 
 ### Run in Browser
 ```bash
-npm test -- front_end/core/sdk/NetworkManager.test.ts
+./dt test front_end/core/sdk/NetworkManager.test.ts
 ```

package/.agents/skills/ui-eng-vision-local-lit-renderer/SKILL.md

@@ -34,14 +34,18 @@ existing element containers.
         that method. **Do not** introduce Widget lifecycle methods
         (`performUpdate`) on classes that do not inherit them.
 
-3.  **Import Modern Templating**:
+3.  **Import Modern Templating (Named Imports Only)**:
 
-    *   Import the `Lit` rendering system inside the view module:
+    *   Always use named imports from `../../ui/lit/lit.js`:
 
         ```typescript
-        import {html, render, nothing} from '../../ui/lit/lit.js';
+        import {html, nothing, render, Directives, type LitTemplate} from '../../ui/lit/lit.js';
         ```
 
+    *   **NEVER** use namespace imports like `import * as Lit` or reference
+        `Lit.nothing` / `Lit.render`. Named imports enable better tree-shaking and
+        maintain consistent codebase style.
+
 4.  **Modern Component Mapping**:
     *   **MANDATORY**: You **MUST** read and load [ui_engineering.md](../../../docs/ui_engineering.md) first to understand specific component mappings (e.g., Toolbar vs `devtools-toolbar`). Do not assume standard Lit defaults.
     *   If unsure, also consult the [automatic migration code](../../../scripts/eslint_rules/lib/no-imperative-dom-api.ts)
@@ -115,13 +119,53 @@ existing element containers.
     *   The Gerrit Code Review UI cannot identify moved blocks of unchanged code.
     *   If blocks of code need to be reordered, create a "prefactoring" change that first extracts the code that needs to be reordered into a named helper functions and pause the migration, waiting user confirmation.
 
-12. **Micro-Commit Strategy**:
+12. **Embedding Pre-Existing `UI.Widget` Instances via `UI.Widget.WrapperWidget`**:
+
+    *   Use `${widget(UI.Widget.WrapperWidget, {widget: input.childWidget})}` when
+        embedding widgets owned by `UI.ViewManager`
+        (`TabbedViewLocation.tabbedPane()`, `StackLocation.widget()`) or when
+        conditionally moving a shared widget instance between containers
+        (`{widget: shouldShow ? this.#sharedWidget : null}`).
+    *   `WrapperWidget` automatically handles showing and detaching the inner
+        widget and forwards calculateConstraints without requiring custom wrapper
+        classes.
+
+13. **Declarative `<devtools-split-view>` Guidelines**:
+
+    *   **CSS Sizing**: Ensure `<devtools-split-view>` has `flex: auto; height: 100%;`
+        in CSS so it fills available container space and doesn't collapse to 0x0.
+    *   **Reuse Existing Settings for `showMode`**: When binding `show=${...}`
+        declaratively on `<devtools-split-view name="...">`, reuse the existing
+        `SplitWidget` setting (`{vertical?: {size, showMode}, horizontal?: {size, showMode}}`)
+        for `showMode` rather than creating new boolean settings (which loses user
+        preferences and requires `KnownContextValues.ts` updates).
+    *   **Keep Environment Overrides in Templates**: Keep environment overrides
+        (like `!input.isTraceApp`) in the `DEFAULT_VIEW` template (e.g.,
+        `show=${!input.isTraceApp && input.isSidebarOpen ? 'both' : 'main'}`)
+        rather than baking them into the presenter's setting state.
+    *   **Clean Up Resizers**: Do not leave unused `resizer-widget` classes in
+        templates; `<devtools-split-view>` manages its own built-in splitter
+        unless custom elements are explicitly registered with `installResizer`.
+
+14. **Declarative Long-Press Action Buttons (`bindToAction`)**:
+
+    *   Legacy `UI.Toolbar.Toolbar.createLongPressActionButton(action, [subButtons])`
+        maps declaratively to nesting option `<devtools-button>` elements directly
+        inside `<devtools-button ${bindToAction('action-id')}>...</devtools-button>`.
+
+15. **Audit Removed `UIStrings`**:
+
+    *   If a `UIStrings` entry becomes unused during template migration, verify
+        that a conditional UI branch (such as a dynamically shown checkbox, button,
+        or tooltip) wasn't accidentally dropped before deleting the string.
+
+16. **Micro-Commit Strategy**:
 
     *   Do not attempt to convert every helper method and UI component in a single monolithic commit. Break the template extraction into **small, self-contained micro-commits** (e.g., migrating one helper method, toolbar button, or list item render at a time).
     *   Verify with build and run tests after each micro-commit to guarantee zero regressions and 100% visual parity before moving to the next compartment.
     *   Provide the exact list of files and commit message when presenting progress so the change history remains atomic and easy to review.
 
-13. **Wait for confirmation**:
+17. **Wait for confirmation**:
 
     *   Wait for an explicit confirmation from the user (or Parent Orchestrator Agent) before proceeding to the next step.
 
@@ -130,8 +174,12 @@ existing element containers.
 ## 🔍 Mental Audit (Internal Self-Correction)
 
 *Before reporting back or committing, re-read the instructions and verify:*
-1.  ❓ **Tag Parity**: Did I accidentally change any `span` to `div` (or vice versa)?
-2.  ❓ **Attribute Drop**: Did I drop any `aria-*`, `role`, or custom data attributes?
-3.  ❓ **Clang-Off Boundary**: Is the template wrapped in `// clang-format off`?
-4.  ❓ **Build**: Does the code compile and do visual tests pass with 0% diff?
+1.  ❓ **Named Imports**: Did I use named imports `{html, nothing, render}` from `ui/lit/lit.js` (and no `import * as Lit`)?
+2.  ❓ **Tag Parity**: Did I accidentally change any `span` to `div` (or vice versa)?
+3.  ❓ **Attribute Drop**: Did I drop any `aria-*`, `role`, or custom data attributes?
+4.  ❓ **Clang-Off Boundary**: Is the template wrapped in `// clang-format off`?
+5.  ❓ **Split Views**: Does `<devtools-split-view>` have `flex: auto; height: 100%;` CSS and reuse existing split settings?
+6.  ❓ **String Audit**: Did I verify that any removed `UIStrings` weren't from accidentally dropped UI branches?
+7.  ❓ **Build**: Does the code compile and do visual tests pass with 0% diff?
+
 

package/.agents/skills/ui-eng-vision-logic-consolidator/SKILL.md

@@ -76,7 +76,29 @@ consolidating them into private helper methods with explicit data contracts.
         that first extracts the code that needs to be reordered into named
         helper functions and pause the migration, waiting for user confirmation.
 
-6.  **Wait for confirmation**:
+6.  **No Write-Only State Fields in Prefactor CLs**:
+
+    *   Do not introduce `#state` fields in a logic-consolidation CL that are only
+        written to in that CL and only read in the *next* CL's `DEFAULT_VIEW`.
+    *   Either read them in the prefactor CL (e.g., inside an extracted imperative
+        `#render...` helper) or introduce them in the CL that actually adds
+        `DEFAULT_VIEW`.
+
+7.  **Extract Imperative `#renderSubtreeContent()` Helpers**:
+
+    *   For complex layouts, extracting an imperative `#renderFooContent()`
+        helper in Pass 1 (while keeping the outer container imperative) minimizes
+        the Pass 2/3 diff when converting `#renderFooContent()` to
+        `renderFooContent(input: ViewInput): LitTemplate`.
+
+8.  **Preserve Imperative Cleanup Calls**:
+
+    *   When consolidating DOM/widget references (e.g., replacing
+        `#tabbedLocationHeader` with `#debuggerSidebarTabbedLocation`), preserve
+        imperative cleanup calls like `splitWidget.uninstallResizer(...)` until the
+        imperative container itself is removed.
+
+9.  **Wait for confirmation**:
 
     *   Wait for an explicit confirmation from the user (or Parent Orchestrator Agent) before proceeding to the next step.
 
@@ -86,6 +108,8 @@ consolidating them into private helper methods with explicit data contracts.
 
 *Before reporting back or committing, re-read the instructions and verify:*
 1.  ❓ **Minimal Diffs**: Did I move code blocks around unnecessarily?
-2.  ❓ **State Completeness**: Are all imperative DOM updates now backed by state variables?
-3.  ❓ **Build**: Does the code still compile?
+2.  ❓ **State Completeness & Utility**: Are all state variables actually read in this CL, with no write-only placeholders?
+3.  ❓ **Cleanup Preserved**: Are resizer/listener uninstallation calls preserved during reference consolidation?
+4.  ❓ **Build**: Does the code still compile?
+
 

package/.agents/skills/ui-eng-vision-orchestrator/SKILL.md

@@ -76,6 +76,26 @@ principles.
     clean and focused on high-level orchestration, prefer delegating intense
     execution tasks (like running tests, debugging compilations, or processing
     independent classes in parallel) to specialized subagents.
+13. **Cross-Repo Runtime Coupling Check (`legacy_test_runner` & `blink/web_tests`)**:
+    Before converting TypeScript `private` fields/methods to ES `#private` or
+    removing widget properties (e.g., `.tabbedPane`, `.sidebarPaneStack`,
+    `.threadsSidebarPane`, `.searchInputElement`), search both
+    `front_end/legacy_test_runner/**/*.js` and Chromium's
+    `third_party/blink/web_tests/http/tests/devtools/**/*.js` (which run on
+    `dtf_linux_rel` CQ via `blink_web_tests` and reflectively access private
+    members in untyped JS). Keep accessed members as TypeScript `private` with a
+    `// Accessed in web_tests / legacy_test_runner` comment, or migrate the
+    web_tests first in a dedicated CL.
+14. **Strict CL Splitting Rules**:
+    *   **One Class Per CL for Hybrid Files**: When modernizing files containing
+        multiple classes, extract or migrate secondary classes (e.g.,
+        `QuickSourceView`) into their own dedicated CLs.
+    *   **Separate Infrastructure CLs**: Keep shared `ui/legacy` or component
+        infrastructure changes (e.g., `bindToAction`, `SplitWidget`,
+        `WrapperWidget`) in separate, preceding CLs. Always verify with
+        `cog_api.py diff` before uploading that no changes from later commits
+        leaked into earlier infrastructure CLs.
+
 
 
 --------------------------------------------------------------------------------
@@ -129,6 +149,8 @@ The plan you generate **MUST** follow this structure:
 ## 🛠️ Passes Checklist
 - [ ] **Pass 0: Baseline & Safety Scaffolding**
   - Assigned to: `ui-eng-vision-test-scaffolder`
+- [ ] **Pass 0.5: Privatize & Dead-Code Cleanup**
+  - Mechanical prefactor: convert TypeScript `private` to ES `#private` and remove dead code
 - [ ] **Pass 1: Logic Consolidation**
   - Assigned to: `ui-eng-vision-logic-consolidator`
 - [ ] **Pass 2: Lit-HTML Rendering**
@@ -149,10 +171,18 @@ The plan you generate **MUST** follow this structure:
         regressions.
     2.  Pay extra attention not to skip this step.
 
+### Privatize & Dead-Code Cleanup (Pass 0.5)
+
+*   **Trigger Condition**: Baseline tests green.
+*   **Actions**:
+    1.  Perform the **Cross-Repo Runtime Coupling Check** against `legacy_test_runner` and `blink_web_tests` first.
+    2.  Convert internal TypeScript `private` fields/methods to ES `#private` (except those reflectively accessed by web tests).
+    3.  Identify and remove unused dead code, redundant containers, or obsolete split widgets in a dedicated prefactor CL so mechanical renames don't clutter logic and view CLs.
+    4.  Verify that all tests and lints pass and stage this prefactor CL before proceeding to logic consolidation.
+
 ### Logic Consolidation
 
-*   **Trigger Condition**: Baseline tests green (or respective previous pass
-    staged).
+*   **Trigger Condition**: Pass 0.5 staged (or baseline tests green if 0.5 skipped).
 *   **Subskill to Import/Delegate**: `ui-eng-vision-logic-consolidator` (Delegate to a subagent to maintain focus)
 *   **Actions**:
     1.  Extract manual elements, constructor DOM configurations, and imperative

package/.agents/skills/ui-eng-vision-test-scaffolder/SKILL.md

@@ -65,20 +65,23 @@ logical regressions are introduced during modernization.
 
 Always detect the execution environment first to run tests successfully:
 
-### Scenario A: Google-Internal Cog/Cider Workspaces (PRIMARY PATH for Google Workspaces)
+### Scenario A: Google-Internal Cog Workspaces (PRIMARY PATH for Google Workspaces)
 
 *   **Detection**: Triggered if the workspace path starts with `/google/cog/` or
     `/google/src/`.
-*   **Why it is required**: Raw commands like `npm run test` or `autoninja` fail
-    because they lack Google cloudtop/virtualization wrapper configurations.
+*   **Execution Guide**: Follow [`devtools-verification`](../devtools-verification/SKILL.md).
 *   **Resolution Steps**:
 
-    1.  Do not run `npm run test` or standard `autoninja` directly.
-    2.  Leverage the Google-specific Cider testing script to compile and run
-        tests in the cloud workspace:
+    1.  Ensure `depot_tools` is at the front of your `PATH`:
 
         ```bash
-        python3 internal/infra/scripts/cider/init_workspace.py test /google/cog/cloud/username/workspace_name --test_filter=front_end/panels/application/IndexedDBViews.test.ts
+        export PATH="/path/to/depot_tools:$PATH"
+        ```
+
+    2.  Execute tests using `./dt test` directly from `chromium/third_party/devtools-frontend/src`:
+
+        ```bash
+        ./dt test front_end/panels/application/IndexedDBViews.test.ts
         ```
 
 ### Scenario B: Standard Chromium Environment (Fallback)
@@ -107,7 +110,7 @@ Always detect the execution environment first to run tests successfully:
         3.  Execute the tests:
 
             ```bash
-            npm run test -- front_end/panels/application/IndexedDBViews.test.ts
+            ./dt test front_end/panels/application/IndexedDBViews.test.ts
             ```
 
 ### Scenario C: ESLint TS Module Resolution Failure (ERR_UNKNOWN_FILE_EXTENSION)
@@ -121,7 +124,7 @@ Always detect the execution environment first to run tests successfully:
         parse the rules:
 
         ```bash
-        npm run build
+        ./dt build
         ```
 
 ### Scenario D: Screenshot Test Fails (Visual Diffs > 0%)
@@ -133,6 +136,33 @@ Always detect the execution environment first to run tests successfully:
     3.  If it's a layout shift, check if you replaced a block element with an inline element (e.g. `div` -> `span`).
     4.  If styles are missing, verify if the test wrapper needs `{includeCommonStyles: true}`.
 
+### Scenario E: Lightweight Test Hook Gotchas (`describe` vs `describeWithEnvironment`)
+
+*   Prefer `describe` with lightweight hooks (`setupLocaleHooks()`, `setupSettingsHooks()`) when full `describeWithEnvironment` is unnecessary.
+*   **Always reset singleton registries in `afterEach`**:
+    When registering actions, shortcuts, or context menus in tests, singleton registries MUST be reset in `afterEach`:
+
+    ```typescript
+    afterEach(() => {
+      UI.ActionRegistration.reset();
+      UI.ActionRegistry.ActionRegistry.reset();
+      UI.ShortcutRegistry.ShortcutRegistry.removeInstance();
+    });
+    ```
+
+    Without these resets, repeated runs (such as `--repeat=10` or CQ flake detection) will fail on iteration 2+ with `Duplicate action ID: '...'`.
+
+*   **GlassPane Container Setup**:
+    If testing UI that opens a `GlassPane` or long-press option menu (e.g. `bindToAction` with long-press buttons) in a test suite using `describe` without `describeWithEnvironment`, call:
+
+    ```typescript
+    beforeEach(() => {
+      UI.GlassPane.GlassPane.setContainer(document.body);
+    });
+    ```
+
+    Otherwise, menu rendering will fail because `GlassPane` lacks an attached container element.
+
 --------------------------------------------------------------------------------
 
 ## 🔍 Mental Audit (Internal Self-Correction)
@@ -141,4 +171,3 @@ Always detect the execution environment first to run tests successfully:
 1.  ❓ **Coverage**: Did I cover all classes in the file, or only the main one?
 2.  ❓ **Stability**: Can the tests run repeatedly without flakiness?
 3.  ❓ **Integrations**: Did I verify that the component mounts correctly?
-

package/.agents/skills/ui-eng-vision-widget-promoter/SKILL.md

@@ -28,11 +28,11 @@ clean `UI.Widget` classes that use native update rendering delegates.
 2.  **Upgrade View Delegates & Inject View**:
 
     *   Migrate the local Lit template strings into a formally exported default
-        view layout:
+        view layout (using named imports `import {html, render} from '../../ui/lit/lit.js';`):
 
         ```typescript
         export const DEFAULT_VIEW: View = (input, output, target) => {
-          Lit.render(html`...`, target);
+          render(html`...`, target);
         };
         ```
 
@@ -67,10 +67,10 @@ clean `UI.Widget` classes that use native update rendering delegates.
 
     *   Remove any `LegacyWrapper` bindings or custom wrappable custom elements.
     *   Replace old panel instantiations with standard `<devtools-widget>`
-        declarative entries:
+        declarative entries (using `const {widget} = UI.Widget;`):
 
         ```typescript
-        html`<devtools-widget .widgetConfig=${widgetConfig(MyWidgetClass, [params])}></devtools-widget>`
+        html`<devtools-widget ${widget(MyWidgetClass, {params})}></devtools-widget>`
         ```
 
     *   Inspect instantiator files (e.g., `ApplicationPanelSidebar.ts`) and

package/.agents/skills/ui-widgets/SKILL.md

@@ -43,7 +43,7 @@ Complex views can be broken down using helper functions defined inside `DEFAULT_
 ```ts
 // clang-format off
 const DEFAULT_VIEW = (input: ViewInput, output: ViewOutput, target: HTMLElement): void => {
-  const renderHeader = (): Lit.LitTemplate => {
+  const renderHeader = (): LitTemplate => {
     return html`<h1>${input.title}</h1>`;
   };
   // ...
@@ -58,10 +58,11 @@ const DEFAULT_VIEW = (input: ViewInput, output: ViewOutput, target: HTMLElement)
 
 ### Composition
 
-* To render a child widget, the parent's View MUST use lit-html directive `UI.Widget.wiget`
+* To render a child widget, the parent's View MUST use the lit-html directive `UI.Widget.widget`.
 * Configuration is passed via the parameters.
 * Properties passed from a parent MUST be declared as public fields on the child presenter class.
 * The framework automatically updates these properties and calls `requestUpdate()` on the child when the parent re-renders.
+* **Pre-existing Widget Instances (`WrapperWidget`):** To render an existing `UI.Widget` instance (such as locations created by `UI.ViewManager`: `TabbedViewLocation.tabbedPane()`, `StackLocation.widget()`) declaratively without creating a custom wrapper class, use `${widget(UI.Widget.WrapperWidget, {widget: myWidgetInstance})}`. `WrapperWidget` automatically forwards constraints, handles attach/detach lifecycle, and supports dynamic widget replacement.
 
 ## Refactoring Legacy Components
 
@@ -106,7 +107,7 @@ render(html`
 **Note:** The `{host: input}` option in `render()` is generally **not required** unless you are using specific Shadow DOM patterns that necessitate it. The `@scope` strategy is the preferred method for style isolation in DevTools widgets.
 
 ### Legacy Interop & Refs
-*   **Raw Elements:** Use `Lit.Directives.ref` to obtain a reference to a raw `HTMLElement` if needed for imperative APIs (e.g., `splitWidget.installResizer(element)`).
+*   **Raw Elements:** Use `Directives.ref` (from `ui/lit/lit.js`) to obtain a reference to a raw `HTMLElement` if needed for imperative APIs (e.g., `splitWidget.installResizer(element)`).
 *   **Child Widgets:** Use `UI.Widget.widgetRef` to obtain the class instance of a child widget if you need to call methods on it directly (though declarative data flow is preferred).
 
 ### Dependencies
@@ -153,12 +154,12 @@ Example: `front_end/panels/my_example/MyExampleWidget.ts`.
 ```ts
 // front_end/panels/my_example/MyExampleWidget.ts
 
-import * as Lit from '../../ui/lit/lit.js';
+import {Directives, html, render} from '../../ui/lit/lit.js';
 import * as UI from '../../ui/legacy/legacy.js';
 
 import myExampleWidgetStyles from './myExampleWidget.css.js';
 
-const {html, render, ref} = Lit;
+const {ref} = Directives;
 
 // 1. Define Input data shape. (Assuming Child Widget configuration for completeness)
 export interface ViewInput {
@@ -241,14 +242,13 @@ Example: `front_end/panels/parent/ParentWidget.ts`. Demonstrates passing state v
 ```ts
 // front_end/panels/parent/ParentWidget.ts
 
-import * as Lit from '../../ui/lit/lit.js';
+import {html, render} from '../../ui/lit/lit.js';
 import * as UI from '../../ui/legacy/legacy.js';
 import {MyExampleWidget} from '../my_example/MyExampleWidget.ts';
 
 import parentWidgetStyles from './parentWidgetStyles.css';
 
-const {html, render} = Lit;
-const {widgetConfig} = UI.Widget;
+const {widget} = UI.Widget;
 
 interface ViewInput {
   title: string;

package/docs/README.md

@@ -71,7 +71,7 @@ below.**
 
 Formats all code using clang-format.
 
-`npm test`
+`./dt test`
 
 Runs all tests on DevTools code.
 

package/docs/contributing/README.md

@@ -157,9 +157,9 @@ be accepted.
 If your patch is finished, we have a few helpful tools to make sure your patch looks good.
 
 As part of the presubmit check, we will automatically run these. You can also run specific
-presubmit checks by using our `npm` commands:
+presubmit checks by using our `./dt` commands:
 
-*   `npm run lint` to perform [ESLint](http://eslint.org) and [Stylelint](http://stylelint.io)
+*   `./dt lint` to perform [ESLint](http://eslint.org) and [Stylelint](http://stylelint.io)
     checks.
 
 To run these presubmit checks without uploading, you can run `git cl presubmit --upload`.
@@ -252,7 +252,7 @@ If reviewers will ask you to change something in your code, follow these steps:
 2. Run `gsync client`.
 3. Optionally, pull latest changes and rebase them with: `git pull --rebase origin main`.
 4. Commit locally to your branch.
-5. Run the linters on your code (e.g. style, coding conventions) via `npm run lint`.
+5. Run the linters on your code (e.g. style, coding conventions) via `./dt lint`.
 6. Finally, upload everything to the server again with `git cl upload`.
 7. Once complete, add a comment similar to "comments addressed, please take a look".
    Without a comment, reviewers will not know about your new patchset.

package/docs/cookbook/dependencies.md

@@ -59,7 +59,7 @@ Chromium licensing to be used, on the basis that it enforces all packages have a
 license that is compatible with a set of pre-defined licensees.
 
 If you want to use a new package as tooling process in engineer workflows, you
-can add the package to the `package.json` and run `npm run install-deps` to
+can add the package to the `package.json` and run `./dt install-deps` to
 check in the new contents.
 
 Only add new license types to `LICENSES` after you received approval from