fix: align GitOps update identifier guidance

[cursor]

Description

Corrects GitOps update guidance so resource_id matches the generic nested-resource convention (app_name / ApplicationSet UUID) and agent_id is passed through params. Adds focused registry coverage for the guidance and dispatch wiring.

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]

Stale comment

1. src/registry/toolsets/gitops.ts: the gitops_application.update contract is still internally inconsistent. This PR fixes the prose description to say resource_id is the app name and agent_id belongs in params, but harness_describe also surfaces bodySchema.description, and that structured metadata still says app_name (path) is passed via params. Under the repo’s architecture guidance, required fields/body format should live in structured metadata, so agents can still receive conflicting update instructions after this change.

Assumptions:

• I treated harness_describe output as part of the architecture contract because CLAUDE.md explicitly prefers structured agent guidance (bodySchema, executeHint, etc.) over prose-only instructions.

Verification:

• pnpm test tests/registry/gitops.test.ts
• pnpm typecheck
• pnpm test

  

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

[cursor]

1. Important — src/registry/toolsets/gitops.ts, tests/registry/gitops.test.ts: gitops_applicationset.update now tells agents to pass resource_id='<appset_id>', but the runtime still does not consume appset_id for this update path. harness_update only copies resource_id into input.appset_id, and this spec never maps appset_id into the request; the real identifier remains body.applicationset.metadata.uid plus params.agent_id. That leaves the changed guidance out of sync with actual generic update behavior, and the new ApplicationSet test does not catch it.
2. Important — tests/registry/gitops.test.ts: the added regression coverage bypasses the shared harness_update layer by calling Registry.dispatch() with app_name / appset_id already populated. Because the bug being fixed is about generic resource_id semantics, these tests would stay green if src/tools/harness-update.ts regressed. A tool-level test through registerUpdateTool() is needed to prove the user-facing contract.

Open questions / assumptions:

• I assumed keeping harness_update.resource_id mandatory is intentional. If so, should gitops_applicationset.update validate resource_id === metadata.uid, or should the guidance explicitly say metadata.uid is authoritative and resource_id is only present because of the shared tool schema?

Brief summary:

• I found two important issues. Local verification after installing dependencies: pnpm test tests/registry/gitops.test.ts, pnpm test tests/tools/tool-handlers.test.ts, pnpm typecheck, and pnpm build all passed.

  

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

[cursor]

Does resource_id actually need to be <appset_id> here? harness_update maps it into input.appset_id, but this update spec never reads appset_id back out (no path/query mapping, and bodyBuilder() only validates body.applicationset.metadata.uid). I spot-checked the built registry with two different resource_id values and got identical PUT /gitops/api/v1/applicationset requests, so this guidance is still stricter than the runtime contract.

[cursor]

This test never goes through harness_update; it calls Registry.dispatch() with appset_id already set, so it does not verify the generic resource_id -> appset_id mapping the PR is documenting. That matters here because the runtime currently ignores appset_id for ApplicationSet update and keys entirely off metadata.uid + agent_id, so this stays green even if the user-facing contract is still wrong.

[Him7n]

@thisrohangupta I have already made the fix in PR

• fix: align GitOps update/delete descriptions with resource_id → app_name mapping + add 77 tests #180 with full proper tests for gitops please take a look there