fix: normalize GitOps list results for search

[cursor]

Description

Normalize GitOps list responses so API-specific array keys like applications, clusters, and repositories also expose items/total for generic consumers such as harness_search. Added regressions for scoped GitOps application search and direct list normalization.

Type of Change

• Bug fix
• New feature
• Refactor
• Documentation
• Other

Checklist

• Tests pass
• Typecheck passes

  

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[cursor]

1. Findings ordered by severity

• Important — src/registry/toolsets/gitops.ts:79-105, src/registry/toolsets/gitops.ts:245, src/registry/toolsets/gitops.ts:290, src/registry/toolsets/gitops.ts:618, src/registry/toolsets/gitops.ts:663, src/registry/toolsets/gitops.ts:712, src/registry/toolsets/gitops.ts:912, src/registry/toolsets/gitops.ts:955, src/registry/toolsets/gitops.ts:1025, src/registry/toolsets/gitops.ts:1066, src/tools/harness-list.ts:69-75, src/registry/extractors.ts:15-21, src/registry/extractors.ts:107-119, tests/registry/registry.test.ts:400-416
gitopsListExtract() fixes harness_search by adding items, but it does so with return { ...raw, items, total }, which makes the registry/public list contract leak GitOps transport keys like applications, clusters, etc. back out to callers. That breaks the repo's shared normalized-list pattern: existing extractors normalize to canonical items/total shapes, while harness_list only compacts result.items. So GitOps list results will now expose both a compact items array and an un-compacted raw array, creating duplicated/inconsistent output and reintroducing API-specific leakage at the wrong abstraction layer. The new registry test hard-codes that leakage as expected behavior by asserting result.applications exists.

2. Open questions/assumptions

• Assumption: the intended contract for registry.dispatch(..., "list", ...) remains the normalized list shape that harness_list/harness_search consume (items + total), not a backward-compatible promise to preserve API-specific array keys. I did not find another consumer in this diff that needs applications to remain public.
• Open question: if preserving raw GitOps keys is intentional for compatibility, should harness_list also suppress or compact those aliases so the public tool output still stays canonical?

3. Summary

• The PR fixes the immediate GitOps search regression, but it does not fully follow Sunil's architecture standards as written because it solves the issue by preserving API-specific list envelopes in the registry/output contract instead of keeping GitOps on the shared extractor/normalized-response path.

  

_{Sent by Cursor Automation: Sunil On Demand Architecture Review}

[cursor]

1. Important: src/registry/toolsets/gitops.ts
   The PR fixes the immediate search bug, but it does so by expanding the shared registry/list contract to preserve raw GitOps transport keys (applications, clusters, etc.) alongside items/total. That conflicts with the shared extractor pattern in src/registry/extractors.ts and with the documented list-output contract in AGENTS.md / CLAUDE.md, which standardize list responses around normalized fields. The new registry assertion in tests/registry/registry.test.ts then locks that GitOps-specific shape in as part of the public contract instead of keeping the compatibility concern at the caller boundary.

Open question / assumption:

• I’m assuming we do not intentionally guarantee raw GitOps array keys from harness_list. If some downstream caller depends on them, that compatibility should be made explicit and handled above the registry layer rather than in the extractor itself.

Verification:

• pnpm test tests/registry/registry.test.ts tests/tools/tool-handlers.test.ts
• pnpm typecheck
• PR CI: build-and-test is green; smoke jobs were still running during review.

Summary:

• The functional bugfix looks good, but I don’t think the current shape fully follows Sunil’s architecture standards because it codifies an API-specific response contract in the shared registry layer.

  

_{Sent by Cursor Automation: Sunil On Demand Architecture Review}

[cursor]

This fixes harness_search, but return { ...raw, items, total } makes the shared registry contract GitOps-specific again. The extractor layer has generally normalized list responses to canonical fields (items, total, plus pagination metadata when needed) rather than preserving transport-specific keys, and the new registry test now hard-codes those raw keys as part of the contract. To stay aligned with Sunil's standards, I think this should normalize to the canonical list shape here and keep any backward-compatibility shim outside the registry layer.