Update contract ID terminology in get_contract_status tool

[kundanrao8507]

User description

• Changed 'contract_id' to 'composite_id' in the input schema and request interface for clarity.
• Updated descriptions to specify the expected format for composite IDs (T-123 for templates, H-123 for historical contracts).
• Adjusted the endpoint construction to reflect the new naming convention.

---

Generated description

Below is a concise technical summary of the changes proposed in this PR:
Clarify the contract status tool schema and GetContractStatusRequest interface by renaming contract_id to composite_id and describing the T-123/H-123 format for template versus historical contracts. Align the getContractStatus endpoint construction with the updated naming so the tool consistently references composite_id when calling the SpotDraft API.

Latest Contributors(1)

User	Commit	Date
achuth10	chore: Refactor projec...	February 05, 2026

This pull request is reviewed by Baz. Review like a pro on (Baz).

[baz-reviewer]

composite_id is now required and contract_id removed — should we keep contract_id as a legacy alias mapped to composite_id?
contract_id => composite_id

_{Finding type: Breaking Changes | Severity: 🔴 High}

---

Want Baz to fix this for you? Activate Fixer

Prompt for AI Agents:

Before applying, verify this suggestion against the current code. In
src/tools/contracts/get_contract_status.ts around lines 7-11 (the
getContractStatusTool.inputSchema) and lines 21-27 (the GetContractStatusRequest
interface and getContractStatus function), preserve backward compatibility for legacy
callers that send contract_id. Change the input schema to accept both composite_id and
contract_id (or use a oneOf/anyOf rule so at least one is required), add contract_id to
the TypeScript request interface as optional, and in getContractStatus compute a
derivedCompositeId = request.composite_id ||
normalizeLegacyContractId(request.contract_id) where normalizeLegacyContractId returns
the value unchanged if it already matches /^[HT]-[0-9]+$/, and if it is a plain integer
string, prefixes it with 'T-'. Then use derivedCompositeId when building the endpoint
(`/v2.1/public/contracts/${derivedCompositeId}/status`). This will avoid breaking
existing integrations while supporting the new composite_id name.