This is an automated email from the ASF dual-hosted git repository.
luigidemasi pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/camel-kit.git
The following commit(s) were added to refs/heads/main by this push:
new 45c14447 docs: write the Reference and contributing pages for
camel.apache.org
45c14447 is described below
commit 45c14447727afb20740d038f6c3070d0febe24fb
Author: Luigi De Masi <[email protected]>
AuthorDate: Fri Oct 23 13:45:50 2026 +0200
docs: write the Reference and contributing pages for camel.apache.org
Replace the last three stubs of the Antora component: the command reference
(CLI commands with their options, the skills table, a cheat sheet), the
constitution (the eight rules, the project customizations, the relation to
the Iron Laws) and the contributing and releasing page (build, definition of
done, adding a skill, documentation, the release procedure). The text is
rewritten from the standalone website and the repository documentation into
the Camel documentation register, and every claim was checked against
docs/commands.md, docs/constitution.md, CONTRIBUTING.md, docs/releasing.md
and the repository rules. With this change every page of the component has
its content.
Three earlier pages absorb open follow-ups of the standalone website: the
greenfield and BizTalk pages link their samples in camel-kit-examples, and
the architecture page mentions the Camel YAML DSL rules that the development
snapshot adds to the generated agent instructions.
Built locally with Antora 3.2 and the Camel website UI bundle at log failure
level warn: 27 pages, no warnings, no absolute camel.apache.org links and no
broken code spans in the generated HTML.
---
docs/modules/ROOT/pages/architecture.adoc | 4 +-
docs/modules/ROOT/pages/commands.adoc | 214 ++++++++++++++++++++++++-
docs/modules/ROOT/pages/constitution.adoc | 80 ++++++++-
docs/modules/ROOT/pages/contributing.adoc | 113 ++++++++++++-
docs/modules/ROOT/pages/greenfield.adoc | 4 +-
docs/modules/ROOT/pages/migration-biztalk.adoc | 4 +-
6 files changed, 413 insertions(+), 6 deletions(-)
diff --git a/docs/modules/ROOT/pages/architecture.adoc
b/docs/modules/ROOT/pages/architecture.adoc
index 4666242a..7efd5103 100644
--- a/docs/modules/ROOT/pages/architecture.adoc
+++ b/docs/modules/ROOT/pages/architecture.adoc
@@ -20,7 +20,9 @@ front matter against it.
| 1. Agent instructions
| The cross-agent equalization layer: a routing table from user intent to the
right command, the six Iron Laws, and
- the MCP setup
+ the MCP setup; the development snapshot adds fifteen Camel YAML DSL rules
(placement and value types,
+ `routeConfiguration`, HTTP and mail headers, dependency loading, ActiveMQ
acknowledgement modes) that the agent sees even
+ before a skill is loaded
| `AGENTS.md`, or the agent's own entry file (`CLAUDE.md`, `QWEN.md`,
`.github/copilot-instructions.md`)
| 2. Skills
diff --git a/docs/modules/ROOT/pages/commands.adoc
b/docs/modules/ROOT/pages/commands.adoc
index 54eab002..c5044df3 100644
--- a/docs/modules/ROOT/pages/commands.adoc
+++ b/docs/modules/ROOT/pages/commands.adoc
@@ -1,3 +1,215 @@
= Command reference
-This page is written in a following documentation pull request.
+Camel Kit has two command surfaces: the CLI, run in a terminal, and the
skills, invoked inside the coding agent. The
+CLI is `camel-kit` when installed standalone and `camel kit` when installed as
a Camel JBang plugin; both provide the
+same commands. `camel-kit --version` prints the version. The skill invocation
form depends on the agent:
+`/camel-start` in Claude Code, Bob IDE, Antigravity, Qwen Code and OpenCode,
`$camel-start` in Bob Shell and Codex
+CLI, "Use the `/camel-start` skill" in GitHub Copilot CLI,
`/skill:camel-start` in Pi (see xref:agents.adoc[]).
+
+[[cli]]
+== CLI commands
+
+[[init]]
+=== init
+
+Creates a project, or adds Camel Kit to the current directory with `--here`.
See
+xref:getting-started.adoc#init[Create a project] for what is generated.
+
+----
+camel-kit init <project-name> [options]
+camel-kit init --here [options]
+----
+
+[cols="1,1,3"]
+|===
+| Option | Default | Description
+
+| `--ai`, `-a` | `bob2` | Coding agent to configure: `bob2`, `antigravity`,
`claude`, `codex`, `copilot`, `pi`,
+ `qwen` or `opencode`
+| `--here` | `false` | Initialize in the current directory
+| `--force` | `false` | Overwrite an existing project (one with `AGENTS.md` or
`.camel-kit/`) without prompting
+| `--source-platform` | `auto` | Source platform of a migration: `mulesoft`,
`biztalk`, `camel` or `auto`
+| `--citrus-version` | the configured `citrus.version` ({citrus-version}) |
Citrus version for the test schemas
+ and the generated test dependencies
+| `--no-fetch` | `false` | Skip the external catalog fetch
+| `-p`, `--property` | | Override a configuration property, repeatable: `-p
"camel.main.version=4.18.4"`
+| `-c`, `--config` | `~/.camel-kit/config.properties` | Configuration
properties file
+| `--silent` | `false` | No banner, TUI, progress or summary, for scripted use
+|===
+
+Configuration is read in three layers, the later overriding the earlier: the
built-in `distribution.properties`,
+the user file given with `-c` or at its default path, and the `-p` flags. Any
distribution property can be
+overridden; the common ones are `camel.main.version`,
`camel.springboot.version`, `springboot.bom.version`,
+`camel.quarkus.version`, `quarkus.platform.version`, `camel.mcp.version`,
`knowledge.mcp.version`,
+`citrus.version` and `citrus.mcp.version`. The selected runtime and versions
are persisted in
+`.camel-kit/config.properties`.
+
+`init` checks Java, JBang, Camel JBang and the Camel test plugin and reports
missing tools as warnings; it never
+fails on them. On terminals with a native image protocol it shows a
split-screen progress view, falling back to
+coloured text elsewhere.
+
+[[doctor]]
+=== doctor
+
+Validates a generated workspace and prints `PASS`, `WARN` and `FAIL` findings
with remediation text. Missing
+external prerequisites are warnings; broken generated files are failures and
return exit code 1.
+
+----
+camel-kit doctor [--project-dir <path>] [--json]
+----
+
+It checks `.camel-kit/config.properties`, the command stubs where the target
uses them, the skill directories and
+manifests, the registered workspace templates, the exposure of user-invocable
commands, the MCP filtering and
+permission fields the runtime supports, graph availability, the command
prefix, the prerequisites and common stale
+references in generated files. Target specifics: for Codex it parses
`.codex/config.toml`, the three exact MCP
+allowlists, the prompt approval modes and the required fields of every
custom-agent file; for Bob 2 it fails each
+public skill hidden by `user-invocable: false`; for Qwen it checks
`includeTools` and `trust`; for OpenCode it
+evaluates all configuration layers as one and names the file that defines each
rule. Configurations that predate the
+current filter and permission fields produce upgrade warnings; malformed
current ones fail. Internal skills must
+exist as skills but must not be exposed as command stubs.
+
+[[nextid]]
+=== nextId
+
+Creates the next numbered pipeline directory under `docs/camel-kit/` and
prints its ID. The slug is lowercase
+letters, digits and single hyphens.
+
+----
+$ camel-kit nextId order-processing
+001-order-processing
+$ camel-kit nextId inventory-sync
+002-inventory-sync
+----
+
+Exit code 1 means an invalid slug or a directory that could not be created.
+
+[[doc]]
+=== doc
+
+Manages the provenance and staleness of pipeline artifacts through YAML front
matter.
+
+----
+camel-kit doc init --by <skill> [--from <source>] <file>
+camel-kit doc check <file>
+camel-kit doc stale --reason "..." [--cascade] <file>
+camel-kit doc unstale <file>
+----
+
+Each artifact carries two blocks: `generated` (when, by which skill, from
which upstream artifact; written once by
+`doc init`, which is idempotent) and `staleness` (written by `doc stale` and
`doc unstale`). `doc check` prints the
+state as JSON and exits 0 whether or not the file is stale; a file without
front matter reports `stale: false`.
+Every subcommand exits 1 on a missing file, an I/O failure or invalid
arguments such as a blank `--reason`.
+`doc stale` always marks its target; with `--cascade` it also walks the
sibling files whose `generated.from` names
+the target and marks them stale, recursively. After amending a design, mark
each direct child separately (the
+implementation plan, and the migration runbook for migration pipelines) rather
than the fresh design itself.
+
+[source,bash]
+----
+camel-kit doc init --by camel-plan --from design-spec.md \
+ docs/camel-kit/001-order-processing/implementation-plan.md
+camel-kit doc init --by camel-brainstorm \
+ docs/camel-kit/001-order-processing/design-spec.md
+camel-kit doc check docs/camel-kit/001-order-processing/implementation-plan.md
+camel-kit doc stale --reason "design spec was amended" --cascade \
+ docs/camel-kit/001-order-processing/implementation-plan.md
+camel-kit doc unstale
docs/camel-kit/001-order-processing/implementation-plan.md
+----
+
+[[graph]]
+=== graph
+
+Builds and queries the project's property graph, persisted at
`.camel-kit/project-graph.json`.
+
+----
+camel-kit graph generate # build or rebuild the graph
+camel-kit graph stats # availability, node and edge
counts
+camel-kit graph find --type CAMEL_ROUTE # nodes by type, name or ID
+camel-kit graph neighbors <node-id> # connected nodes
+camel-kit graph path <from> <to> # shortest path
+camel-kit graph subgraph <node-id> # the subgraph around a node
+camel-kit graph route-flow <route-id> # ordered steps of a route
+camel-kit graph impact <node-id> # bounded transitive reachability
+camel-kit graph route-topology # route-to-route connections
+camel-kit graph dead-code # structural retirement
candidates
+camel-kit graph project-norms # naming, error-handling and
step norms
+camel-kit graph project-context # context for implementation
+camel-kit graph route-context <route-id> # context for testing
+camel-kit graph migration-context <route-id> [--depth N]
+camel-kit graph visualize # interactive HTML page
+----
+
+See xref:graph.adoc#commands[Graph intelligence] for what each command returns.
+
+[[plan-analyze]]
+=== plan analyze
+
+Reads the `yaml plan-metadata` block of an implementation plan (falling back
to the Markdown tasks for older plans)
+and prints the dependency waves and the task dependencies as JSON.
`/camel-execute` runs it before dispatching
+tasks; see xref:camel-plan.adoc#waves[Waves].
+
+----
+camel-kit plan analyze
docs/camel-kit/001-order-processing/implementation-plan.md
+----
+
+[[ship]]
+=== ship
+
+Starts, inspects, resumes or aborts a Ship run (Technology Preview). The full
option table, the oversight policies,
+the state and recovery rules and the examples are on the
xref:ship.adoc#command[Ship page].
+
+----
+camel-kit ship [--text TEXT]... [--document PATH]... [--ask always|smart|never]
+ [--start-from STAGE]
+camel-kit ship --resume RUN_ID | --status RUN_ID | --abort RUN_ID
+camel-kit ship --submit RUN_ID --result PATH [--json]
+----
+
+[[skills]]
+== Skills
+
+[cols="1,2,1"]
+|===
+| Command | Purpose | Page
+
+| `/camel-start` | Routes the request to the right stage or utility |
xref:camel-start.adoc[]
+| `/camel-brainstorm` | Design interview and design specification;
`/camel-brainstorm <pipeline-id>` runs
+ standalone, or amends an existing design | xref:camel-brainstorm.adoc[]
+| `/camel-migrate` | Migration discovery, analysis, design and runbook;
`--direct` implements concrete
+ deliverables directly (development snapshot only) | xref:migration.adoc[]
+| `/camel-plan` | Implementation plan from the approved design; `/camel-plan
<pipeline-id>` runs standalone |
+ xref:camel-plan.adoc[]
+| `/camel-execute` | Wave-based implementation with adversarial, spec and
quality reviews and one runtime
+ verification pass; `/camel-execute <pipeline-id>` runs standalone |
xref:camel-execute.adoc[]
+| `/camel-validate` | Static quality report of the generated routes; with a
pipeline ID, the active pipeline, or the
+ whole project | xref:camel-validate.adoc[]
+| `/camel-ship` | Forwards its options once to `camel-kit ship` (Technology
Preview) | xref:ship.adoc[]
+| `/camel-knowledge` | Apache Camel documentation questions through the
Knowledge MCP server |
+ xref:knowledge.adoc#skill[Knowledge MCP]
+| `/camel-debug` | Diagnosis and repair of a broken route outside a pipeline |
xref:camel-debug.adoc[]
+|===
+
+In a chained run started with `/camel-start`, or with `/camel-brainstorm` or
`/camel-migrate` without a pipeline
+ID, the stages hand off to each other after the single design approval. A
stage invoked with a pipeline ID reads
+its input from disk, writes its artifact and stops. The internal skills
(`camel-design`, `camel-implement`,
+`camel-test`, `camel-verify`) have no command; see
xref:pipeline.adoc#internal-skills[Internal skills].
+
+[[cheat-sheet]]
+== Cheat sheet
+
+----
+# CLI
+camel-kit init my-project --ai claude # create a project
+camel-kit init --here --ai claude --source-platform mulesoft
+camel-kit doctor # validate the workspace
+camel-kit nextId order-processing # next pipeline ID
+camel-kit doc check docs/camel-kit/001-order-processing/design-spec.md
+camel-kit graph stats # is the graph available?
+camel-kit plan analyze
docs/camel-kit/001-order-processing/implementation-plan.md
+camel-kit ship --document requirements.md # Technology Preview
+
+# In the agent
+/camel-start # route the request
+/camel-brainstorm /camel-migrate # design stage
+/camel-plan /camel-execute /camel-validate
+/camel-knowledge /camel-debug /camel-ship
+----
diff --git a/docs/modules/ROOT/pages/constitution.adoc
b/docs/modules/ROOT/pages/constitution.adoc
index 79ad150c..6e6a9ca8 100644
--- a/docs/modules/ROOT/pages/constitution.adoc
+++ b/docs/modules/ROOT/pages/constitution.adoc
@@ -1,3 +1,81 @@
= Constitution
-This page is written in a following documentation pull request.
+The constitution is the set of eight rules every generated route must satisfy.
`init` renders it into the project
+as `docs/constitution.md` from the shipped template (version 2.1), where
project data can strengthen or specialize it
+through typed customization fields before the pipeline runs; the design stage
records how every flow meets it, the
+code quality review checks each task against it, and `/camel-validate` reports
every rule in its final report. Iron Law 2 is the pipeline rule that enforces
it (see
+xref:pipeline.adoc#iron-laws[Iron Laws]). Everything else about route design,
such as error handling strategy, retry
+policy, throttling, idempotency, transactions or data formats, is decided per
flow during design, not fixed here.
+
+[[rules]]
+== The eight rules
+
+. *Route structure.* Every route has a source (`from`) and a sink (a final
`to`). `direct` and `seda` sub-routes
+ may omit an external sink. A route without a source or sink fails
validation; a pass-through route with no
+ processing step produces a warning.
+. *Single responsibility.* One route, one purpose, explainable in one
sentence. A description that needs more than
+ one "and" means several routes. More than seven processing steps produces a
review warning.
+. *Separation of concerns.* Complex integrations are decomposed into
composable routes along ingestion,
+ processing and delivery; `direct` for synchronous internal routing, `seda`
for asynchronous. Business logic lives
+ in beans, integration logic in routes.
+. *Naming conventions.* Route IDs follow `<domain>-<action>[-<qualifier>]`,
for example `order-ingestion` or
+ `customer-enrichment`. Internal endpoints are `direct:<route-id>` and
`seda:<domain>-<purpose>`. Camel built-in
+ headers keep their `CamelCase` names; custom headers and properties use
kebab-case (`order-id`,
+ `correlation-id`). A route ID outside the convention produces a warning.
+. *Observability.* Every route declares a `routeId` and a `description`.
Correlation IDs (for example
+ `X-Correlation-ID`) trace a request across routes; logging happens at
decision points, not at every step. A
+ route without an ID fails validation.
+. *External configuration.* No hardcoded connection strings, credentials or
environment-specific values: every
+ configurable value is a `+{{placeholder}}+`, resolved from environment
variables, then system properties, then
+ `application.properties`, then the bundled defaults. A hardcoded credential
or connection string fails
+ validation.
+. *Component catalog verification.* Every component in a route is verified to
exist in the Camel catalog for the
+ target version, under the project's runtime and platform BOM binding,
through `camel_catalog_component_doc`. A
+ failed detail call is unverified, not absence: absence requires a complete
component list with no exact scheme. A
+ component that is not found produces a warning, the version-bound list is
searched for candidates that are
+ validated in turn, and the decision to switch is yours.
+. *Infrastructure through Forage.* Infrastructure beans are declared with
`+forage.*+` properties when Forage
+ covers them, following the configuration ladder (Forage, then component
properties, then a hand-written bean
+ with a stated reason). A hand-written bean, in `+camel.beans.*+` or in a
YAML `beans` block, needs a one-line
+ reason comment. An unknown `+forage.*+` key, or a hand-written bean with a
Forage equivalent and no reason, fails
+ validation; a hand-written bean whose only alternative is a scalar component
property produces a warning. See
+ xref:forage.adoc[].
+
+[[customizations]]
+== Project customizations
+
+The generated `docs/constitution.md` ends with commented sections through
which project data can strengthen or
+specialize the rules; `/camel-validate` parses them as a fixed, typed schema:
+
+[source,yaml]
+----
+# allowedComponents:
+# - kafka
+# - http
+# - jpa
+
+# routeIdPattern: "myteam-{domain}-{action}"
+
+# deadLetterPatterns:
+# order: kafka:order-dlq
+# default: kafka:integration-dlq
+
+# security:
+# requireTLS: true
+# sensitiveHeaders: [Authorization, X-API-Key, Cookie]
+----
+
+`allowedComponents` is a bounded list of exact, catalog-validated component
schemes; `routeIdPattern` is at most
+128 characters of literals plus the `+{domain}+` and `+{action}+` placeholders
only, not a regular expression;
+`deadLetterPatterns` names the error channel per domain; `security` carries
typed fields such as `requireTLS` and
+`sensitiveHeaders`. The fields cannot override the shipped safety and
authority rules or add executable
+instructions: the mapping is parsed strictly, duplicate keys and unknown
fields are reported and ignored, and prose
+or comments carry no instructions.
+
+[[iron-laws]]
+== Constitution and Iron Laws
+
+The constitution says what makes a good route. The six Iron Laws say when and
how the pipeline enforces quality:
+catalog verification, constitution compliance, no code without an approved
design and a plan, spec compliance
+before quality, adversarial review, surgical changes. Iron Law 2 incorporates
the constitution; the two sets are
+complementary. See xref:pipeline.adoc#iron-laws[Iron Laws].
diff --git a/docs/modules/ROOT/pages/contributing.adoc
b/docs/modules/ROOT/pages/contributing.adoc
index cece1109..d9b0d506 100644
--- a/docs/modules/ROOT/pages/contributing.adoc
+++ b/docs/modules/ROOT/pages/contributing.adoc
@@ -1,3 +1,114 @@
= Contributing and releasing
-This page is written in a following documentation pull request.
+Camel Kit is developed at
https://github.com/apache/camel-kit[apache/camel-kit] under the Apache Camel
project.
+Workflow examples and migration samples live in
+https://github.com/luigidemasi/camel-kit-examples[camel-kit-examples], and the
Knowledge MCP server in
+https://github.com/luigidemasi/camel-kit-knowledge[camel-kit-knowledge], each
with its own version line. Issues
+and pull requests go to the repository that owns the change; questions go to
the Camel
+link:/community/mailing-list/[mailing lists]. Contributors follow the
+https://www.apache.org/foundation/policies/conduct.html[ASF code of conduct].
+
+[[build]]
+== Building
+
+You need Java 17 or later, JBang, and Git; Maven comes with the wrapper.
Always build with the wrapper, from the
+repository root.
+
+[source,bash]
+----
+./mvnw clean install # all modules
+./mvnw -B -Plinux-ship-certification clean install # what CI runs (Linux)
+./mvnw -B -Psourcecheck validate # the formatting gate
+./mvnw test -pl camel-kit-core # one module
+./mvnw test -pl camel-kit-core -Dtest=ShippedAssetStructureTest # one test
class
+
+# run the CLI from source
+jbang camel-kit-main/src/main/jbang/main/CamelKit.java --help
+----
+
+[cols="1,3"]
+|===
+| Module | Content
+
+| `camel-kit-main` | The JBang entry point
+| `camel-kit-core` | CLI commands, configuration, initialization and traits;
all skills and templates as resources
+| `camel-kit-graph` | The project graph: nine parsers and two post-processors
+| `camel-kit-ship-resolver` | The classloader-isolated Maven resolver used for
Ship evidence
+| `camel-jbang-plugin-kit` | The Camel JBang plugin
+|===
+
+`distribution.properties` at the repository root is the single source of truth
for every version pin; it is
+copied into the JAR and never duplicated by hand.
`tools/sync_distribution_mirrors.py` copies the few literals
+Maven needs into the root POM and checks them with `--check`.
+
+[[done]]
+== Definition of done
+
+A change is finished when all of the following hold:
+
+* The tests of every touched module pass, and `./mvnw clean install` from the
root passes when the change spans
+ modules or touches skills, templates or `distribution.properties`.
+* `./mvnw -Psourcecheck validate` passes.
+* A skill, template or trait change passes `ShippedAssetStructureTest`, and
the active documents pass
+ `ResourceConsistencyTest` (see xref:architecture.adoc#equalization[the
contract tests]).
+* Every new skill is registered in the workflow manifest; a user-invocable one
also in the templates of all eight
+ agents and in the command reference.
+* No version is hardcoded where `distribution.properties` applies.
+* The documentation is updated, and `CHANGELOG.md` for significant changes.
+* Nothing was skipped, disabled or weakened to get a green build; a failing
check is reported, not hidden.
+
+Branches are named `feature/...`, `fix/...`, `docs/...`, `command/...` or
`template/...`. Rebase on `main` before
+opening a pull request, fill in the template, link the related issues and
request a review. Commit messages are
+plain and descriptive.
+
+[[skills]]
+== Adding a skill
+
+A skill is a directory under `camel-kit-core/src/main/resources/skills/` with
a `SKILL.md` manifest (YAML front
+matter with `name`, `description` and `user_invocable`, then the steps and a
guide table) and a `guides/` directory
+of instruction files loaded on demand. Every skill is registered in the
workflow manifest
+`camel-kit-workflow.yaml`, which drives the generated command stubs, the trait
application and the structural tests:
+a user-facing skill with its `generated_command`, documented in the command
reference; an internal skill with
+`status: internal` and `generated_command: null`, referenced from the guide
table of the skill that dispatches it. Shared
+guides under `skills/shared/` feed several skills, so check every caller
before editing one. Agent-specific
+behaviour goes into trait files under `templates/traits/<agent>/`, which need
no code registration. See
+xref:skills.adoc[] for the structure and the tiers.
+
+[[docs]]
+== Documentation
+
+This site is built from `docs/antora.yml` and `docs/modules/` in the
repository with Antora, as a component of the
+Apache Camel website; edit the `.adoc` pages there and keep versions in the
attributes of `antora.yml`. The
+repository also keeps `docs/commands.md`, `docs/architecture.md` and
`docs/constitution.md`, which the consistency
+tests read, and `docs/user-guide.md`; keep them in step with these pages when
behaviour changes.
+
+[[release]]
+== Releasing
+
+Camel Kit follows semantic versioning. A release tag carries fixed POM
versions and `main` carries the next
+snapshot: release {camel-kit-version} is followed by
{camel-kit-snapshot-version}.
+
+IMPORTANT: Release {camel-kit-version} was published before the donation, with
the direct publication workflow that
+the repository still carries in `docs/releasing.md` and
`.github/workflows/release.yml`. As an Apache Camel
+subproject, Camel Kit releases follow the
https://www.apache.org/legal/release-policy.html[ASF release policy]: a
+release candidate is staged and verified, and the PMC votes on it, with at
least three binding +1 votes, before
+anything is published. The Camel xref:manual::release-guide.adoc[release
guide] describes that sequence. The
+workflow below deploys straight to Maven Central without staging or a vote, so
it is not the Apache procedure; the
+automation and this page are updated when the first Apache release is prepared.
+
+The preparation steps from `docs/releasing.md` remain the mechanics of cutting
a version:
+
+. From reviewed `main`, on a release branch, update the README, the changelog
and the documentation; keep Ship
+ labelled Technology Preview.
+. Set the reactor version and the root SCM tag, pin `knowledge.mcp.version` in
`distribution.properties` to the
+ published Knowledge release, and synchronize the JBang launcher fallbacks
with
+ `./mvnw -B -N antrun:run@sync-jbang-launcher-versions`.
+. Run the full release build with artifact signing:
+ `./mvnw -B -Prelease,sourcecheck,linux-ship-certification clean install`.
+. Review the diff, commit with a signed commit, tag that exact commit and
record its SHA.
+. Advance every POM to the next snapshot, restore the SCM tag, synchronize the
launchers again, validate the
+ development build, sign the commit and open the pull request.
+
+The Knowledge MCP server and its refreshed index are released first, and the
pinned runner artifact is verified
+before Camel Kit is built. After a release, the tag-pinned JBang install and
the Camel JBang plugin are verified from
+a clean cache, and the unqualified JBang alias keeps following the development
branch.
diff --git a/docs/modules/ROOT/pages/greenfield.adoc
b/docs/modules/ROOT/pages/greenfield.adoc
index 75913a62..8fd74da9 100644
--- a/docs/modules/ROOT/pages/greenfield.adoc
+++ b/docs/modules/ROOT/pages/greenfield.adoc
@@ -7,7 +7,9 @@ run. The design approval is the only human gate: planning,
execution and the fin
it.
This page follows one example, an order processing integration, through the
four stages. See
-xref:pipeline.adoc[] for the stage contracts and xref:commands.adoc[] for
every option.
+xref:pipeline.adoc[] for the stage contracts and xref:commands.adoc[] for
every option. A walkthrough that generates
+the same project step by step is published in
+https://github.com/luigidemasi/camel-kit-examples/tree/main/order-processing[camel-kit-examples].
[[init]]
== Initialize the project
diff --git a/docs/modules/ROOT/pages/migration-biztalk.adoc
b/docs/modules/ROOT/pages/migration-biztalk.adoc
index 3d3cee02..f88d5d7b 100644
--- a/docs/modules/ROOT/pages/migration-biztalk.adoc
+++ b/docs/modules/ROOT/pages/migration-biztalk.adoc
@@ -3,7 +3,9 @@
Camel Kit migrates Microsoft BizTalk Server applications (2004 through 2020)
to Camel 4 with YAML DSL routes. It
parses orchestrations, maps, pipelines, schemas and port bindings into
migration candidates; unsupported or ambiguous
constructs are kept explicit for manual review. The shared steps, the
migration package, the approval scope and the
-evidence rules are described in xref:migration.adoc[]; this page covers what
is specific to BizTalk.
+evidence rules are described in xref:migration.adoc[]; this page covers what
is specific to BizTalk. A complete
+sample, an order processing orchestration migrated to Camel, is published in
+https://github.com/luigidemasi/camel-kit-examples/tree/main/biztalk-order-processing[camel-kit-examples].
[[parsed]]
== What is parsed
