[Feature]: Represent supported agents with JSON Schema and Zod validation

[Drswith]

Problem or opportunity

Quantex currently keeps supported agent definitions as TypeScript modules under src/agents/definitions/, with the core contract expressed in src/agents/types.ts. This gives type safety at compile time, but it also couples catalog data changes to source-code edits and makes it harder to validate the agent catalog as a stable data contract.

As the supported-agent matrix grows, new agent additions and metadata changes would be easier to review, validate, and potentially reuse if the catalog were represented as data with an explicit schema rather than as many hardcoded TS files.

Desired outcome

Supported agents should be representable as JSON-compatible catalog data validated by a JSON Schema and a Zod runtime schema.

The implementation should preserve Quantex's current lifecycle-CLI scope while making the agent catalog contract more machine-actionable for:

• local validation during development and CI
• future generated documentation/support matrices
• safer additions of supported agents
• clear separation between catalog data and TypeScript behavior code

Scope and non-goals

In scope:

• Define a stable schema for supported-agent catalog entries.
• Add Zod validation that rejects invalid catalog data before it reaches CLI behavior.
• Generate or maintain JSON Schema from the same source of truth where practical.
• Migrate agent metadata that is pure data out of per-agent hardcoded TS modules.
• Keep behavior-specific code, such as custom version parsers or execution logic, in TypeScript behind an explicit extension point if needed.
• Update OpenSpec for the agent catalog contract before implementation.

Non-goals:

• Do not turn Quantex into a workflow orchestration platform.
• Do not introduce remote/dynamic catalog fetching unless a separate OpenSpec change accepts that behavior.
• Do not weaken existing install/update/version-probe contracts.
• Do not hide executable behavior inside JSON where TypeScript remains the safer boundary.

Linked discussion or prior context

Raised from local maintainer request on 2026-05-12: "??????agent???json schema+zod??????????ts??".

Relevant repo areas:

• src/agents/types.ts
• src/agents/definitions/
• openspec/specs/agent-catalog/spec.md
• docs/agent-support-matrix.md

Which durable artifacts should this likely create or update?

• OpenSpec
• ADR

Done when

• An OpenSpec change defines the intended agent catalog contract and migration boundaries.
• Supported-agent catalog data has a JSON-compatible representation with runtime Zod validation.
• JSON Schema is emitted, checked in, or otherwise available from the same maintained contract.
• Existing CLI behavior for listing, resolving, installing, checking, and updating agents remains compatible unless explicitly changed by the OpenSpec change.
• Tests cover valid and invalid catalog entries, including platform install methods and version/update metadata.
• Documentation or support-matrix generation is updated if it currently depends on hardcoded TS definitions.

Guardrails

• I understand this issue should promote durable outcomes into repo-native docs instead of adding new ad hoc root markdown files.
• I understand this issue should stay within Quantex's lifecycle CLI scope unless an explicit decision changes that scope.