Catalog and compatibility

The catalog is the knowledge WeHarness draws on. Every signed-in user can browse it under Catalog in the sidebar, where components are compared across the eight areas and against your repositories. MCP tools can search it too. The planner, guidance and the Catalog page read the same release, so they always show the same data.

What it contains

Kind	What it is
Skills	Guidance bundles for building agent behaviour, for example approval-gated effects and durable waits.
Reference plans	Worked architecture plans for example projects.
Rubrics	Criteria used to judge plans and results.
Components	Frameworks, tools and services: LangGraph, Mastra, CrewAI, Google ADK, Pydantic AI, OpenAI Agents and others.
Capabilities	What a component does, with typed inputs and outputs: for example “executes steps durably across restarts”.
Research profiles	Exact package versions that were checked to resolve together.

Capabilities

WeHarness finds components by what they do, not by their names. When you or the agent describe a task in any language, WeHarness finds the closest capabilities by meaning and then the components that declare them. For example, “the workflow must continue after the server restarts” leads to durable execution, and so to Temporal and Inngest.

Components with a pinned version also describe each capability for that version:

• the permissions it needs;
• its preconditions, such as credentials coming from the environment;
• its effects;
• the runtime it needs.

These descriptions are WeHarness’s own contract for using the capability, not observed behaviour of the package.

Stages

Every component version moves along one promotion path. The Catalog page shows where each one is.

Stage	Meaning
Discovered	Known from its documentation only.
Collected	Its README was retrieved and fingerprinted.
Reviewed	A WeHarness maintainer reviewed its licence, commands, telemetry and secret access.
Contract-tested	Its capability contracts passed a recorded test.
Scenario-tested	A recipe built on it passed its scenarios in a fresh environment.
Supported	A maintainer decided to support it, on all of the above.

A version moves one stage at a time. Each step is a recorded decision with its evidence. A pinned version comes with a hash-locked dependency list, so a recipe installs exactly what was resolved. Today no component is past collected.

Recipes

A recipe builds an agent on pinned component versions and judges it by scenarios. There are three so far:

Recipe	What it does
R01	Builds a new Python agent with Google ADK for a small shop. A refund above 50 EUR waits for a person’s approval.
R02	Repairs a TypeScript Mastra tool that sent the payment service a wrong payload.
R03	Repairs a LangGraph workflow that made a large refund without approval and lost earlier steps’ state.

A repair recipe also proves its defect: its scenarios run first on the broken app, where the defect must show and unrelated behaviour must work, then on the repaired one, where every scenario must pass.

When a recipe runs, WeHarness:

1. starts a fresh sandbox;
2. installs exactly the recipe’s hash-locked dependency list with the runtime it names;
3. runs each scenario;
4. judges each scenario with the same typed checks as Evals.

A run records the runtime it got and the lock’s fingerprint. The Catalog page shows the last runs beside the component versions they cover. A passed run is the evidence a maintainer needs for the test stages; it does not promote anything by itself.

Use-case families

The Catalog page lists the ten kinds of agent system WeHarness qualifies compositions for, from a new agent with tools (Q01) to existing production traces (Q10). Each states the behaviour and the failure a qualification must show, and which recipes cover it so far. A family counts as qualified only with executed evidence across its offered compositions; none does yet.

Upstream quarantine

WeHarness checks PyPI and npm once a day for new releases of the catalog’s components. A release the catalog does not pin is in quarantine: WeHarness does not recommend it as checked and does not use it in a recipe until a maintainer reviews it. Work already running keeps the versions it pinned.

Labels say what the evidence is

Labels never say more than the evidence shows. Nothing in the catalog is labelled verified.

Label	Meaning
Draft, not reviewed	Written by WeHarness, not yet reviewed.
Reviewed / Contract-tested / Scenario-tested	Later review and test stages, as they are reached.
Supported	Shown only when an entry has passed all stages and is active. No entry has this label yet.
Integration untested	A framework or tool we know about but have not tested with WeHarness.
Metadata resolved only	The listed versions resolve together on paper; they have not been run.
On hold / Withdrawn / Deprecated	A decision was recorded against this exact content.

Releases and decisions

The catalog is published in releases. Each entry has a content fingerprint (digest), and releases never change. Decisions such as putting an entry on hold or withdrawing it are added to an append-only log for that exact digest. Publishing an older release again cannot bring back an entry that was withdrawn. Each entry page shows its digest, its release and the full decision history.

Compatibility

For each project, WeHarness compares the declared dependencies (see Search and the index) with the catalog’s research evidence. Each finding cites both sides: the line in your project and the catalog evidence.

Finding	Severity	Meaning
Runtime incompatible	Blocking	Your project allows a Node version older than the researched version of a dependency requires.
Known advisory	Blocking	The declared version is in a range with a published security advisory.
Known incompatible	Blocking	These exact versions are known not to resolve together.
Possible conflict	Warning	Your declared ranges allow a known-incompatible combination.
Outside researched versions	Warning	Research evidence covers other versions than the one you declare.
No researched profile	Warning	No research covers this package yet.
Runtime not declared	Warning	A dependency needs a specific Node version and your project does not say which one it uses.
Unknown	Warning	A manifest could not be read, so compatibility cannot be judged.
Within researched profile	Info	Your version is among the researched versions. Research profiles are metadata-only, so this is still not a verified combination.

No findings does not mean everything is compatible. It means no catalog component was found among your declared dependencies.