luigidemasi commented on issue #79: URL: https://github.com/apache/camel-kit/issues/79#issuecomment-6336895324
> Comment by [luigidemasi](https://github.com/luigidemasi) on 2026-07-30 ([original](https://github.com/luigidemasi/camel-kit/issues/149#issuecomment-5135190590)). --- PR luigidemasi/camel-kit#170 merged as `7a535e67`, completing the Pi/Linux worker path and the first real end-to-end fixture. That Delivery checkbox is now checked. I also re-checked the Acceptance Criteria against the merged code, expecting them to have drifted behind the implementation. They mostly had not. Two are now checked; the other 23 are correctly unchecked. Recording why, so the next slice does not have to rediscover it. The two now checked are the ones whose subject is the controller itself rather than the user-facing command, and both were re-derived independently rather than taken from the implementation's own claims: - **Input and artifact digests invalidate stale downstream stages on resume.** `ShipRun.inputDigest` chains each stage over its predecessors' output and artifact digests, `ShipController.resume` re-reads context and artifacts from disk (not from a trusted manifest) and restarts the earliest stage whose recomputed digest no longer matches. `ShipControllerTest.resumeRestartsTheEarliestStaleOrIncompleteStage` asserts exactly that: editing `design.md` restarts PLAN while DESIGN stays completed; deleting `discovery.md` restarts DISCOVERY and resets DESIGN. - **The controller derives the local Stamp result from mandatory check outcomes.** `ShipLocalStamp.deriveStatus` is a pure function over required checks, the canonical constructor re-derives and rejects a mismatched status, every production check is constructed `required=true`, worker prose cannot commit VALIDATE, and outcomes come from process facts rather than text. `ShipCoordinatorTest.preplantedPassingStampCannotPromoteValidation` shows a hand-planted passing stamp still failing the run. One caveat worth knowing: `completed-with-waiver` is dead in production — there is no waiver input anywhere, so only `pass` and `fail` are reachable. ## Delivery evidence - `ShipCoordinatorLiveIT` passed 1 test with 0 failures, errors, and skips under `-Plinux-ship-certification`, driving a document-defined Camel Main integration through Discovery, Design, Plan, Execute, deterministic validation, and Citrus against real Pi `0.83.0` and Node `22.22.2`. - `./mvnw -B clean install` passed the full six-module reactor, `./mvnw -B -Psourcecheck validate` passed, and CI passed on Java 17, 21, and 25. ## Why the rest stay unchecked The building blocks are real and well tested — atomic and interruption-safe state writes, deterministic artifact/catalog/build/Citrus validation, and redacted command evidence all exist with tests. What is missing is that nothing user-facing reaches them. Two findings decide it: 1. **`ShipCoordinator` has no production caller.** `ShipCommand` constructs `ShipController` directly, and outside tests nothing constructs the coordinator. Every criterion whose subject is a completed workflow, a produced run report, or a real end-to-end run is therefore satisfied only inside test code. 2. **The wired `--resume` does not preserve pending work.** `ShipController.resume` treats any non-`COMPLETED` stage as the restart point, resets it, and starts a new attempt. `ShipCommandTest.supportsStartFromResumeStatusAndAbort` asserts exactly that outcome: `attempts() == 2` after resuming a `RUNNING` `DESIGN` stage. The mechanism that actually preserves an in-flight attempt — recovering the durable worker result and committing it at the same attempt number — lives in the coordinator and is unreachable today. So wiring the command to the coordinator is not a cosmetic last step; it is what makes the lifecycle criteria true. ## The live gate is manual, not automated Worth recording because it bounds what the end-to-end criterion currently proves. CI does run `-Plinux-ship-certification`, but `CAMEL_KIT_SHIP_LIVE_PI` is never set in any workflow and `ShipCoordinatorLiveIT` self-skips through `Assumptions.assumeTrue` when it is absent. The fixture has only ever passed on a maintainer machine; it is silently skipped in CI and has never been green there. That is defensible for a fixture needing an authenticated provider, but it should be deliberate: either wire credentials into a gated job, or state the manual-gate status in the documentation. Otherwise the project keeps a required end-to-end check that can pass by being skipped, which is the failure mode this issue forbids for Citrus tests. ## What remains before closure - No guarded publication. The workspace is staged as a directory that explicitly does not change the live project, and nothing applies a validated candidate back after the oversight gate — the end-to-end run stops at a staged candidate. - No usable pause. A run cannot display worker questions or accept answers, so `--ask always|smart` does not yet behave as specified. - `ShipCommand` does not reach the coordinator, with the resume consequence above. - The command is registered in neither the standalone entry point nor the Camel JBang plugin, and there is no public runtime bootstrap for Pi/Node discovery, Maven repository and timeout selection, or explicit experimental-version consent. - The `camel-ship` skill still owns a second prompt-driven state machine with its own state file, staleness detection, resume, and start-from. - CLI help exists on the command itself, but repository documentation, migration guidance, and the website still describe the legacy prompt-owned flow. Website impact stays **required** and remains deferred to that cutover, so documentation lands with the command rather than ahead of it. Issue luigidemasi/camel-kit#169 is independent hardening and does not block closure here. -- 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]
