A toolbox is not a platform. The interfaces make the difference.

A small tool should solve a complete, useful problem by itself. But a collection of good tools becomes more powerful only when their inputs, outputs and limitations can be understood outside their original pages.

Moruneva is publishing a small machine-readable block catalog (JSON) as a discoverability aid. It lists a curated set of existing, callable JavaScript modules—not every site page and not a hosted API. The catalog includes their source paths, entry functions, input and output contract versions, and the known boundaries that a caller must respect.

1. Discover what is actually callable

A browser form is an interface for a person. A reusable JavaScript function is a building block for a developer. A public Agent API would be a third capability, involving authentication, permissions, request budgets, security controls and operational monitoring. These are not the same product claim.

2. A tiny fictional example: two numbers that mean different things

Suppose a webhook checker outputs a field called event_total with the meaning delivery_count. A sales report expects event_total with the meaning paid_order_count. Both may be valid numbers. Neither can automatically answer the other question.

Producer: event_total = 13
meaning: delivery_count
unit: count

Consumer requires: event_total
meaning: paid_order_count
unit: count

Result: meaning_mismatch
Next: inspect the actual mapping and source of truth

Use the free Block Seam Preflight to inspect the two declared interfaces. Even if every declaration matches, you still need to run the real pipeline against independently checked outcomes. The tool is intentionally not an integration certificate.

3. Use the right block for the next question

After checking a declaration, the next failure may be a value error rather than a type or version error. The Field Mapping Evidence Check compares two authorized, pseudonymous CSV snapshots by an explicit key; it can count unequal fields and ambiguous duplicate IDs. It does not determine which system is correct.

If the question becomes “Did the customer get what the project promised?”, use the Acceptance vs Observation Workbench to separate drafted acceptance checks from supplied event/receipt observations. Its scenarios are not verified or accepted merely because logs exist.

This is a useful manual review sequence, not a claim that these pages currently transfer your files automatically between each other. Real adapters must specify schema changes, data boundaries, time-window alignment, failure behavior and permissions. The catalog does not invent those adapters.

4. Read a versioned contract before writing a connector

The JSON catalog identifies existing in-process modules and the runtime functions to call. Some modules accept the common moruneva.block-input.v1 envelope; others use their own plan/incident or CSV request shape. Do not put a generic envelope around a custom input simply because both modules publish a version constant.

Catalog: /block-catalog.json
Example entry: seam_preflight
Module: /blocks/seam-preflight.js
Function: buildFromInput
Input: moruneva.block-input.v1
Output: moruneva.seam-preflight.v1
Decision: human_review_required

All current catalog records are limited to **in-process use**, with bounded data handling and no direct authority to change a customer's system. For any cross-tool workflow, write a new adapter and integration fixture that exercises actual source, transformation, destination and independent expected outcome. A matching version string alone is not enough.

5. Grow a library by making each block useful

A growing library of focused tools is valuable when each page helps someone finish a real task, each result travels in a predictable format, and accompanying writing explains the limits. Quantity alone cannot establish adoption. Measure whether users can find a block, understand it, get a useful result, and return for a related job.

For a one-off task, a spreadsheet or existing platform check may be faster. The right test is not whether Moruneva can generate more pages; it is whether a specific workflow becomes clearer, safer or less tedious than the available alternative.

Read the detailed seam example → · Privacy limits → · Share a specific integration obstacle →