Extending VAMOS

Choose one extension boundary and follow its canonical developer guide:

Goal	Canonical guide	Owning area
Define an ad-hoc or built-in problem	Adding a problem	foundation/problem
Add crossover, mutation, repair, or initialization	Adding an operator	engine/operators
Add a search lifecycle	Adding an algorithm	engine/algorithm
Accelerate a stable numerical primitive	Adding a backend	foundation/kernel
Add a quality indicator	Adding a metric	foundation/quality_indicators

Changes to the CLI, studies, or run artifacts and exact replay use their own boundaries. Do not place orchestration in a numerical extension or create a second public facade.

Public examples use vamos, vamos.algorithms, vamos.problems, and vamos.ux.api. Registry and implementation imports are internal contributor surfaces. Every extension needs a small deterministic or seeded test, a registry/resolution test where applicable, and documentation of the supported public route.

Stable VAMOS 1.x contracts follow the public deprecation and schema-transition policy. Internal and experimental contracts should still be replaced comprehensively rather than gaining duplicate spellings or paths.

path: docs/dev/add_problem.md
path: docs/dev/add_operator.md
path: docs/dev/add_algorithm.md
path: docs/dev/add_backend.md
path: docs/dev/add_metric.md
path: docs/dev/cli.md
path: docs/dev/studies.md
path: docs/dev/run_artifacts_and_replay.md