| Dimension | Shared | Only in A | Only in B | Overlap |
|---|---|---|---|---|
| Sections | 0 | 3 | 3 | 0% |
| Commands | 0 | 0 | 2 | 0% |
| Section tags | 1 | 2 | 2 | 20% |
What each file covers
Sections
0 shared · 3 only in A · 3 only in B- − Shared Test Helper Boundary
- − Bundled Plugin Imports
- − Intent
- + Agent Tools Performance
- + Guardrails
- + Verification
Commands
0 shared · 0 only in A · 2 only in B- + pnpm test <file>
- + pnpm build
Section tags
1 shared · 2 only in A · 2 only in B- − build
- − code-style
- + performance
- + agent-behaviour
- test
Line diff
openclaw/openclaw · test/helpers/AGENTS.md
@@ −1 @@
1# Shared Test Helper Boundary
2
3This directory holds shared test helpers reused by core and bundled plugin
4tests.
5
6## Bundled Plugin Imports
7
8- Shared helpers in this tree must not hardcode repo-relative imports into
9 `extensions/**`.
10- When a helper needs a bundled plugin public surface, go through
11 `src/test-utils/bundled-plugin-public-surface.ts`.
12- Prefer `loadBundledPluginApiSync(...)`,
13 `loadBundledPluginRuntimeApiSync(...)`,
14 `loadBundledPluginContractApiSync(...)`, and
15 `loadBundledPluginTestApiSync(...)` for eager access to exported surfaces.
16- Prefer `resolveRelativeBundledPluginPublicModuleId(...)` or
17 `resolveBundledPluginPublicModulePath(...)` when a helper needs a module id
18 or filesystem path for dynamic import, mocking, or loading a plugin entrypoint
19 such as `index.js`.
20- If `vi.hoisted(...)` is involved, do not call imported helper functions from
21 inside the hoisted callback. Resolve the module id outside the callback or
22 switch to `vi.doMock(...)`.
23- Do not keep plugin-local deep mocks or private `src/**` knowledge in shared
24 helpers. Move those helpers into the owning bundled plugin package instead.
25
26## Intent
27
28- Keep shared helpers aligned with the same public/plugin boundary that
29 production code uses.
30- Avoid shared helper debt that makes core test lanes depend on bundled plugin
31 private layout.
32
openclaw/openclaw · src/agents/tools/AGENTS.md
@@ +1 @@
1<!-- Agent tool test performance notes for avoiding heavyweight plugin/channel runtime loads. -->
2
3# Agent Tools Performance
4
5Tool tests should not load full channel or plugin runtimes for static tool
6descriptions.
7
8## Guardrails
9
10- Message-tool discovery should flow through shared discovery helpers and
11 lightweight channel artifacts before falling back to a full channel plugin
12 load.
13- Channel-specific tool schemas, action lists, and static capabilities belong
14 in plugin-owned helpers that are reused by both the full plugin and the
15 lightweight artifact.
16- Do not add direct bundled-plugin imports to agent tool tests for schema or
17 capability assertions. If the production path needs the same data, promote a
18 small public artifact instead.
19- If a single assertion starts paying multi-second import/setup cost, split the
20 static descriptor path from runtime execution instead of adding more mocks
21 around the broad import.
22
23## Verification
24
25- For `src/agents/tools/*.test.ts` performance work, compare targeted file
26 runtime with `pnpm test <file>` before/after.
27- Run `pnpm build` when adding or changing bundled plugin artifacts.
28
@@ −1 +1 @@
1−# Shared Test Helper Boundary
1+<!-- Agent tool test performance notes for avoiding heavyweight plugin/channel runtime loads. -->
22
3−This directory holds shared test helpers reused by core and bundled plugin
4−tests.
3+# Agent Tools Performance
54
6−## Bundled Plugin Imports
5+Tool tests should not load full channel or plugin runtimes for static tool
6+descriptions.
77
8−- Shared helpers in this tree must not hardcode repo-relative imports into
9− `extensions/**`.
10−- When a helper needs a bundled plugin public surface, go through
11− `src/test-utils/bundled-plugin-public-surface.ts`.
12−- Prefer `loadBundledPluginApiSync(...)`,
13− `loadBundledPluginRuntimeApiSync(...)`,
14− `loadBundledPluginContractApiSync(...)`, and
15− `loadBundledPluginTestApiSync(...)` for eager access to exported surfaces.
16−- Prefer `resolveRelativeBundledPluginPublicModuleId(...)` or
17− `resolveBundledPluginPublicModulePath(...)` when a helper needs a module id
18− or filesystem path for dynamic import, mocking, or loading a plugin entrypoint
19− such as `index.js`.
20−- If `vi.hoisted(...)` is involved, do not call imported helper functions from
21− inside the hoisted callback. Resolve the module id outside the callback or
22− switch to `vi.doMock(...)`.
23−- Do not keep plugin-local deep mocks or private `src/**` knowledge in shared
24− helpers. Move those helpers into the owning bundled plugin package instead.
8+## Guardrails
259
26−## Intent
10+- Message-tool discovery should flow through shared discovery helpers and
11+ lightweight channel artifacts before falling back to a full channel plugin
12+ load.
13+- Channel-specific tool schemas, action lists, and static capabilities belong
14+ in plugin-owned helpers that are reused by both the full plugin and the
15+ lightweight artifact.
16+- Do not add direct bundled-plugin imports to agent tool tests for schema or
17+ capability assertions. If the production path needs the same data, promote a
18+ small public artifact instead.
19+- If a single assertion starts paying multi-second import/setup cost, split the
20+ static descriptor path from runtime execution instead of adding more mocks
21+ around the broad import.
2722
28−- Keep shared helpers aligned with the same public/plugin boundary that
29− production code uses.
30−- Avoid shared helper debt that makes core test lanes depend on bundled plugin
31− private layout.
23+## Verification
24+
25+- For `src/agents/tools/*.test.ts` performance work, compare targeted file
26+ runtime with `pnpm test <file>` before/after.
27+- Run `pnpm build` when adding or changing bundled plugin artifacts.
3228
