Fix resource scope PR feedback

[cursor]

Description

Fixes follow-up scope feedback from PR #182 by failing loudly for explicit org/project scope without matching IDs/defaults, filtering broad scoped search fan-out to compatible resource types, and preserving the resource_scope Zod descriptions.

Type of Change

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

Checklist

• Tests pass
• Typecheck passes

Verification:

• pnpm test tests/registry/registry.test.ts tests/tools/tool-handlers.test.ts tests/utils/url-parser.test.ts
• pnpm typecheck
• pnpm build
• pnpm test

  

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 2 committers have signed the CLA.

✅ thisrohangupta
❌ cursoragent
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[cursor]

Stale comment

1. Important: src/registry/index.ts now treats scopeOptional as full account/org/project support. That widens every pre-existing scopeOptional resource, not just the six multi-scope read resources this PR is trying to fix. A concrete example is scs_component_vulnerability in src/registry/toolsets/scs.ts: its path builder only has account mode (no artifact_id) and artifact/project mode (artifact_id present), but harness_describe/harness_search will now advertise and accept resource_scope="org" via src/tools/harness-describe.ts and src/tools/harness-search.ts. Because there is no org-only path, that request falls through to the account endpoint instead of failing locally, which breaks the repo's explicit-scope and fail-loud rules.

2. Important: src/utils/url-parser.ts now injects resource_scope through applyUrlDefaults() for every tool, but only harness_list, harness_get, and harness_search declare that input. harness_create, harness_update, and harness_delete also call applyUrlDefaults(), so write scope now changes implicitly when the caller pastes a URL even though the write-tool schemas never expose or document that behavior. That makes scope resolution depend on the URL parser instead of the tool contract and goes beyond the read-only scope called out in tasks/todo.md for this change.

  

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

[cursor]

Stale comment

1 finding remains before this fully matches the repo's scope-contract rules:

• src/tools/harness-describe.ts: the new generic scopeHint overstates omitted-scope behavior for template, which is scopeOptional: true and does not fall back to configured org/project defaults when resource_scope is absent.

The two earlier architecture issues from the prior pass look addressed:

• scopeOptional is no longer treated as implicit tri-scope support.
• URL-derived resource_scope is now limited to the read tools that actually declare it.

  

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

[cursor]

Stale comment

The earlier scopeOptional / URL-derived scope / scopeHint issues look addressed, and the focused verification on this head is green:

• pnpm test tests/registry/registry.test.ts tests/tools/tool-handlers.test.ts tests/utils/url-parser.test.ts
• pnpm typecheck
• pnpm build

One architecture issue still remains before this fully matches Sunil's scope-contract standards; see the inline comment.

  

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

[cursor]

Stale comment

1 important finding remains before this fully matches Sunil's architecture standards.

• src/utils/url-parser.ts: template URLs still opt into URL-derived resource_scope, but this PR intentionally removed template supportedScopes. That leaves pasted account-level template URLs outside the runtime scope contract; see the inline comment for the concrete failure path.

Verification:

• pnpm test tests/registry/registry.test.ts tests/tools/tool-handlers.test.ts tests/utils/url-parser.test.ts
• pnpm typecheck

CI snapshot:

• build-and-test (20) passed
• build-and-test (22) passed
• smoke-test matrix is still running

  

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

[cursor]

Stale comment

1 important finding remains before this fully matches Sunil's architecture standards.

• src/registry/index.ts: explicit project scope now resolves org/project defaults for query/body injection, but pathBuilder still receives only the raw input. That leaves template v1 writes on the account path when callers set project scope through the public update tool via params.resource_scope; see the inline comment for the concrete reproduction.

Assumption:

• I validated the remaining issue on the current head by running the built harness_update path locally with configured HARNESS_ORG/HARNESS_PROJECT and params:{ resource_scope: "project", version_label: "v2" }.

Verification:

• pnpm typecheck
• pnpm build
• pnpm test tests/registry/registry.test.ts tests/tools/tool-handlers.test.ts tests/utils/url-parser.test.ts
• pnpm test

The earlier scopeOptional, write-tool URL scope, template scopeHint, and template URL allowlist issues look addressed on this head. CI’s build-and-test jobs are passing; the smoke-test matrix is still running.

  

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

[cursor]

1 important finding remains before this fully matches Sunil's architecture standards.

• src/registry/toolsets/templates.ts: adding supportedScopes makes resource_scope part of the template contract across operations, but the public write tools still do not surface a first-class resource_scope input. On this head the runtime path works only via params.resource_scope, so harness_describe(resource_type="template") now advertises a scope selector that the write-tool schemas do not actually expose.

Verification on the current head:

• pnpm install --frozen-lockfile
• pnpm test tests/registry/registry.test.ts tests/tools/tool-handlers.test.ts tests/utils/url-parser.test.ts
• pnpm typecheck
• pnpm build

The earlier scope threads are addressed on this head and have been resolved.

  

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

[cursor]

Adding supportedScopes here widens the documented resource_scope contract for all template operations, not just list/get. The runtime now honors that on writes too, but only through the generic params escape hatch: on this head I reproduced harness_update(resource_type="template", resource_id="my-template", params:{ resource_scope:"project", version_label:"v2" }) emitting the correct project-scoped v1 path.

The problem is that the registered write-tool schemas still do not expose a top-level resource_scope field at all. For example, harness_update only publishes resource_type, resource_id, url, body, org_id, project_id, and params. So harness_describe(resource_type="template") now tells agents to set resource_scope=..., but the only working path is to smuggle that field through params, which breaks the repo's structured-contract rule for agent-facing metadata.

I’d either add explicit resource_scope inputs to the write tools, or keep template supportedScopes/scope guidance limited to the read paths you actually want to advertise.