luigidemasi opened a new issue, #79: URL: https://github.com/apache/camel-kit/issues/79
> Imported from [luigidemasi/camel-kit#149](https://github.com/luigidemasi/camel-kit/issues/149), opened by [luigidemasi](https://github.com/luigidemasi) on 2026-07-16. > Closed on 2026-08-19 without a linked pull request. --- ## Description Replace the prompt-owned `/camel-ship` sequence with a small local workflow controller that makes the existing Brainstorm → Plan → Execute → Validate pipeline reliable, resumable, and independent of any one harness's internal orchestration. Camel-Kit is a local development tool. Ship protects workflow correctness and avoids accidental credential or state leakage; it does not attempt to defend against a malicious process already running as the developer. The primary user-facing contract is: ```text camel-kit ship [--text TEXT]... [--document PATH]... ``` Harness-native commands such as `/camel-ship`, `$camel-ship`, or `/skill:camel-ship` must be thin wrappers around that local command. They must not implement a second workflow. Initial context may be omitted, supplied as text, supplied as one or more documents, or combined. A requirements document is never mandatory. This work builds on luigidemasi/camel-kit#24, luigidemasi/camel-kit#65, and luigidemasi/camel-kit#121. ## Current Status As of 2026-08-18, PRs luigidemasi/camel-kit#164 through luigidemasi/camel-kit#175 delivered the local controller, bounded Pi/Linux worker, process-interruption recovery, deterministic evidence and validation, guarded publication, contextual resume, truthful pause/status output, configuration, the registered `camel-kit ship` and `camel kit ship` entry points, and the replacement of the legacy prompt-owned harness assets with thin delegates to the registered command. Repository and migration documentation landed with those PRs, and the website was cut over to the delivered workflow on 2026-08-19. The authenticated Pi/Linux run completed on 2026-08-19: a document-driven workflow through the registered `camel-kit ship` entry point on the maintained Pi 0.83.0 / Node 22.22.2 configuration finished all five stages with a passing Stamp and guarded publication. All acceptance criteria are met. ## Problems Addressed 1. The legacy prompt-owned Ship flow lets the orchestrating model update state, choose transitions, interpret failures, and write the final Stamp. 2. Ship and its child skills can both chain stages, so work can run twice or bypass the selected oversight mode. 3. Input handling is ambiguous: a positional value can mean a file, text, or pipeline ID, and a bare invocation has no stable run identity. 4. Resume depends on model-written state and does not reliably invalidate stale downstream artifacts. 5. Build, validation, and test completion can be reported in prose without retaining the actual command result. 6. The registered controller still coexists with legacy prompt-owned harness assets and documentation, so those entry points do not yet share one workflow implementation. ## Product Boundary Ship is a local orchestrator, not a daemon, secrets service, hostile-process sandbox, or release-attestation system. Ship will: - own stage order and durable run state; - preserve the selected `always`, `smart`, or `never` oversight mode; - launch bounded stage workers and prevent workers from committing controller transitions; - use a worktree or staging directory for implementation changes; - run deterministic Camel validation, build, and Citrus checks; - retain enough command evidence to explain the final result; - resume after ordinary process interruption and invalidate stale downstream work. Ship will not require: - a dedicated service account, system service, TPM, biometric approval, OS keyring, or protected UI; - native pre-model interception or a custom plugin for every harness; - a provider-credential broker or per-artifact remote-use consent ledger; - HMAC event chains, signed interaction receipts, content-addressed evidence quarantine, or release signing; - exact OS, architecture, ABI, Node, package-tree, or executable-closure certification; - evidence-backed dispositions for every Camel-Kit harness before the first useful release. Provider credentials remain owned by the selected coding harness or provider tooling. Ship must not persist them or include them in command arguments, logs, reports, or project artifacts. Optional OS facilities may be used by the harness, but they do not affect Ship support. ## Expected User Experience ```text camel-kit ship camel-kit ship --text "Consume Kafka orders and send them to Salesforce" camel-kit ship --document requirements.md camel-kit ship --document requirements.md --text "Prefer YAML and Simple; no Java" camel-kit ship --resume <run-id> camel-kit ship --resume <run-id> --text "Use eu-west-1" camel-kit ship --status <run-id> camel-kit ship --abort <run-id> camel-kit ship --start-from plan camel-kit ship --ask always|smart|never ``` - No context starts a short discovery conversation. - Supplied material is included in discovery input before questions are requested. The worker is instructed to report only unresolved questions; Ship does not claim it can prove that a model will never repeat one. - Related questions may be grouped to avoid unnecessary interaction turns. - `always` pauses at each approval point. - `smart` pauses for material ambiguity and before implementation. - `never` may choose and record reasonable defaults, but still stops for missing tools, failed mandatory checks, or actions requiring authority the user did not grant. - A user can resume an interrupted run or start from validated existing design/plan artifacts. - The user never has to invoke Brainstorm, Plan, Execute, or Validate manually during a normal Ship run. ## Architecture ### Local controller `camel-kit ship` runs as an ordinary user process. It is the only component that writes its run state or commits a stage transition. No background service or privileged installation is required. The controller stores a compact run record in a user-owned local state directory. Updates use write-to-temp plus atomic replacement and preserve run consistency across ordinary process interruption. Complete OS/power-loss durability is not an acceptance criterion. Ordinary SHA-256 digests bind inputs and outputs for staleness detection; they are not security attestations. A run records: - run ID, project identity, and selected oversight mode; - current stage and stage status; - input paths/text and their digests; - design, plan, and generated-artifact digests; - worker attempts and concise failure information; - validation/build/test commands, versions, exit status, and retained log paths; - the final local Stamp report. ### Stages and workers The controller manages these stages: ```text DISCOVERY -> DESIGN -> PLAN -> EXECUTE -> VALIDATE -> COMPLETED ``` `PAUSED`, `FAILED`, and `ABORTED` are run outcomes, not separate states for every failure subtype. Each stage receives a typed request and returns a typed result. The first supported worker is Pi on Linux. Harness commands delegate through thin wrappers; other worker backends can be added when they have an actual maintainer and test path. Discovery, design, plan, and validation are read-only with respect to application source. Execute works in a dedicated git worktree or staging directory. Accepted changes are published only after the configured approval and validation gates. ### Evidence and Stamp The controller, not worker prose, decides whether required checks ran successfully. It records the executable/version, arguments with secrets redacted, exit status, and retained output for: - route naming and artifact checks; - Camel catalog/schema validation; - dependency/runtime consistency; - build and package commands; - required Citrus test discovery and execution. The Stamp is a local run report with `pass` or `fail`. This issue exposes no waiver authority or `completed-with-waiver` user flow. The Stamp describes what ran on this machine; it is not a signed attestation, certification, or guarantee for another installation. ### Harness compatibility Compatibility is capability-based: - `supported`: a maintained configuration covered by a live end-to-end test; - `experimental`: runnable but not covered by the supported live gate; - `incompatible`: a required capability is known to be absent; - `untested`: no current result is known. Unknown versions may run with an explicit experimental warning. Ship reports the detected harness/runtime versions but does not snapshot or certify their complete package closure. ## Acceptance Criteria ### Command and discovery - [x] `camel-kit ship` accepts no context, text, documents, and combined context. - [x] A bare invocation creates a run and starts discovery. - [x] Missing, empty, malformed, and unreadable documents produce distinct actionable errors. - [x] Supplied context is delivered to discovery before questions, and the worker is instructed to report only grouped unresolved questions. - [x] `--ask always|smart|never` follows the behavior described above. - [x] Thin harness commands invoke the same local controller rather than duplicating the workflow. ### Lifecycle and recovery - [x] Within a controller-backed run, only the controller writes run state and commits stage transitions. - [x] State updates preserve consistency across ordinary process interruption through atomic replacement. - [x] Input and artifact digests invalidate stale downstream stages on resume. - [x] `--resume` preserves pending work and does not duplicate a completed attempt. - [x] `--start-from` accepts existing artifacts only after checking required files and their current digests. - [x] Implementation changes occur in a dedicated worktree or staging directory and are not published before the selected oversight gate. - [x] Cancellation terminates the active stage worker and leaves the run resumable or with an explicit `FAILED` or `ABORTED` outcome. ### Verification and completion - [x] Incorrect route suffixes, runtime/config mismatches, forbidden Java, missing dependencies, and malformed manifests are detected deterministically. - [x] Required Citrus tests are discovered and executed; an empty or skipped required test set cannot pass. - [x] Build, validation, and test evidence records executable/version, redacted arguments, exit status, and retained logs. - [x] The controller derives the local Stamp result from mandatory check outcomes. ### First usable support - [x] One Pi/Linux configuration completes a non-skipped authenticated no-context or document-driven workflow through the registered `camel-kit ship` or `camel kit ship` entry point. - [x] The run report records detected Pi, Node, Java, Camel, OS, and architecture versions for diagnostics. - [x] An unknown Pi or Node version can run only with an explicit experimental warning. - [x] Missing Pi or Node fails with installation guidance; Ship resolves its Camel validation payloads and does not require a separately installed Camel CLI. - [x] Other worker backends are not blockers for closing this issue. ### Documentation - [x] CLI help, repository documentation, migration guidance, and the website describe the delivered local workflow. - [x] Documentation explains explicit context flags, oversight modes, resume/start-from, experimental-version warnings, evidence retention, publication/recovery, the manual authenticated live gate, Stamp `pass`/`fail` semantics, and the non-goals above. ## Existing Implementation PRs luigidemasi/camel-kit#150 through luigidemasi/camel-kit#161 introduced the original resolver, validation, lifecycle, storage, publication, and conformance building blocks. PRs luigidemasi/camel-kit#162 and luigidemasi/camel-kit#163 were closed because they were not required by this MVP. PR luigidemasi/camel-kit#164 completed the keep/simplify/delete reset while retaining reusable validators and tests. PRs luigidemasi/camel-kit#165 through luigidemasi/camel-kit#170 delivered the compact controller, bounded Pi worker, recoverable worker results, workflow coordinator, and Pi/Linux acceptance boundaries. PRs luigidemasi/camel-kit#171 through luigidemasi/camel-kit#174 then wired the command to that coordinator, added guarded publication, made pauses and status actionable, and registered Ship with user configuration on both public command surfaces. PR luigidemasi/camel-kit#175 replaced the legacy prompt-owned `camel-ship` skill and its guides, harness traits, modes, rules, and handoff text with thin delegates to the registered command; harness commands no longer maintain a second `.camel-kit/pipeline.json` workflow. ## Delivery - [x] Align ADR-0052 and replace the high-assurance delivery plan. - [x] Map merged Ship code into keep, simplify, and delete buckets with tests for retained behavior (luigidemasi/camel-kit#164). - [x] Implement the local command, compact state model, oversight behavior, resume, and validated start-from. - [x] Add the Pi/Linux worker path and one real end-to-end fixture. - [x] Enable the user-facing command only after the complete local workflow passes. - [x] Replace the legacy prompt-owned harness workflow with thin delegates to the registered command. - [x] Complete one non-skipped authenticated Pi/Linux run through a registered user-facing entry point. - [x] Update repository and website documentation in the same workstream. ## Related Issues - luigidemasi/camel-kit#24 — original autonomous Ship pipeline - luigidemasi/camel-kit#65 — file-based handoff and resume integration - luigidemasi/camel-kit#121 — pipeline-semantic alignment ## Website Impact Required — completed on 2026-08-19. The website now describes the controller-owned workflow: command syntax and configuration, oversight, resume/start-from, support tiers with the current live-gate status, evidence retention, publication, recovery, Stamp semantics, and the migration path from the prompt-owned commands. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
