luigidemasi commented on code in PR #149:
URL: https://github.com/apache/camel-kit/pull/149#discussion_r4452136029
##########
kit/camel-kit-core/src/main/resources/templates/opencode/agents/camel-ship-worker.md:
##########
@@ -0,0 +1,22 @@
+---
+name: camel-ship-worker
+description: Read-only Camel Ship stage worker dispatched by the parent
OpenCode session.
+mode: subagent
+permission:
+ "*": deny
+ mcp: deny
+ read: allow
Review Comment:
[P1] Preserve the host's existing file-read restrictions
This unconditional agent rule overrides existing per-path `ask`/`deny`
rules, including OpenCode's default `.env` approval requirement. With
`permission.read = {"*": "allow", "*protected.txt": "deny"}`, a real child
using the previous worker rejects the protected file, but this worker returns
its contents. The same old/new comparison requires approval for `.env` before
this change and reads it without approval afterward. Both cases reproduce on
OpenCode 1.18.30 and 2.2.5 using harmless canaries. This conflicts with #99 and
the documented requirement that child read access follow the parent's permitted
paths. Preserve effective per-path restrictions when granting read/search
access and add child-level regression coverage that asserts protected contents
never reach the model. OpenCode documents the relevant [agent override and
last-match rules](https://opencode.ai/docs/permissions/).
_AI-generated by Codex on behalf of @luigidemasi._
##########
kit/camel-kit-core/src/main/resources/templates/opencode/agents/camel-ship-worker.md:
##########
@@ -0,0 +1,22 @@
+---
+name: camel-ship-worker
+description: Read-only Camel Ship stage worker dispatched by the parent
OpenCode session.
+mode: subagent
+permission:
+ "*": deny
Review Comment:
[P2] Preserve authorized access to an external Ship state directory
The catch-all also denies `external_directory`, overriding existing
authorization for a specific external path. With the documented
`CAMEL_KIT_SHIP_STATE_HOME` outside the OpenCode project, the controller places
its mandatory briefing there; this worker then fails its first read even if the
host explicitly allows that exact state subtree. I started a real native Ship
run and forwarded its complete task prompt to real children: the previous
worker reads the controller briefing, while this worker fails with an
`external_directory` permission denial, on both OpenCode 1.18.30 and 2.2.5.
Preserve narrowly authorized controller paths, or reject this unsupported
layout before starting native execution; do not grant unrestricted external
access.
_AI-generated by Codex on behalf of @luigidemasi._
##########
kit/camel-kit-core/src/test/java/org/apache/camel/kit/ship/controller/OpenCodeNativeWorkerTest.java:
##########
@@ -0,0 +1,15 @@
+package org.apache.camel.kit.ship.controller;
+
+import org.apache.camel.kit.ship.controller.ShipRun.ExecutionMode;
+
+/**
+ * Validates the shared controller contract for OpenCode native Ship.
Generated assets were verified via a local
Review Comment:
[P2] Complete the generated-entry-point acceptance required by #99
The new Linux smoke/DISCOVERY report is useful progress, but its listed
checks stop at a worker response and model-reported MCP denial. They do not
show a completed workflow with independently verified artifacts and
deterministic validation, or the required oversight, interruption/resume,
abort/timeout, and repeated/stale/conflicting-submission checks. This test
still inherits controller fixtures rather than launching the real host. In
addition, the reported OpenCode 2.2.5 exposes `subagent` with an `agent`
argument, while the generated relay requires `task` with `subagent_type`;
invoking a worker directly does not establish that the registered entry point
is eligible or functional. Please provide that full acceptance through the
generated entry point on a declared supported host version, or obtain an
explicit acceptance-scope waiver. The previous acceptance finding remains open.
_AI-generated by Codex on behalf of @luigidemasi._
--
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]
