feat: add Harness File Store support

[sahilharness]

Add File Store resources for metadata, uploads, and content reads through the existing registry-backed MCP tools.

Description

add file store support.
you can now

• list out all files/folders in a scope
• read content from a file
• create a file
• update content from a file
• delete a file

[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
❌ sahilharness
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[cursor]

1. Medium — src/registry/toolsets/file-store.ts, src/tools/harness-create.ts, src/tools/harness-update.ts, src/tools/harness-delete.ts, src/tools/harness-describe.ts: file_store_item now advertises supportedScopes: ["account", "org", "project"] on a write-capable resource, but the public write tools still do not expose resource_scope and do not opt into URL-derived scope. That means harness_describe tells agents to set resource_scope, yet harness_create / harness_update / harness_delete can only hit account/org File Store writes through undocumented params.resource_scope; with configured defaults they otherwise fall back to project scope. This is a structured discoverability/runtime contract mismatch.
2. Low — src/utils/url-parser.ts, src/registry/toolsets/file-store.ts, tests/utils/url-parser.test.ts: the PR adds File Store URL parsing, but the resource definition still has no deepLinkTemplate, so File Store responses cannot emit openInHarness links even though pasted URLs now parse. There is also no matching url-parser regression coverage for the new file-store segment / URL-default merge path, so this new discoverability surface is one-way and unverified.
3. Low — src/registry/index.ts, README.md: the branch is currently red on pnpm docs:check because adding the new toolset changed the generated resource/toolset counts without regenerating README.md. CI’s pnpm test and pnpm typecheck steps passed on the PR head; docs sync is the remaining failure.

Overall, the File Store endpoint wiring itself is mostly aligned with the repo standards: declarative toolset registration, clean GET vs multipart-body separation, no body leakage in the update preflight, appropriate risk policies, and guarded output shaping for file downloads. The gaps are in shared-tool discoverability / round-trip UX rather than the endpoint mappings themselves.

  

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

[cursor]

file_store_item is now a write-capable resource that advertises account/org/project scope, but the public write tools still do not publish a top-level resource_scope input and they intentionally ignore URL-derived scope on create/update/delete. That means harness_describe(resource_type='file_store_item') now tells agents they can set resource_scope, while harness_create / harness_update / harness_delete can only reach those paths through undocumented params.resource_scope and otherwise fall back to configured project scope. I think this should either be made schema-visible on the write tools or kept out of the advertised multi-scope contract.

[cursor]

This adds File Store URL parsing, but I don't see the corresponding round-trip discoverability follow-through: file_store_item still has no deepLinkTemplate, so responses won't include openInHarness, and there are no matching tests/utils/url-parser.test.ts cases for the new file-store segment / applyUrlDefaults() path. Since URL parsing is a cross-cutting agent-discovery surface, I'd expect the parser, deep links, and regression coverage to land together.