Skip to content

Implement e2e story: delegated sub-agent invocation preserves caller identity for orfe #39

Description

@z0r4n-bot

Context

Issue #31 defines the live e2e contract for orfe.

Most orfe e2e stories prove that a top-level OpenCode agent can invoke orfe and produce the expected GitHub side effects. However, orfe depends on context.agent, so we also need a dedicated OpenCode-integration story that proves delegated execution preserves the sub-agent caller identity rather than the parent agent identity.

This is not primarily a GitHub API story. It is an OpenCode integration story that validates the wrapper boundary used by orfe:

  • a parent OpenCode agent delegates work to a sub-agent
  • the sub-agent invokes orfe
  • orfe resolves the sub-agent caller name from context.agent
  • repo config maps that caller name to the correct GitHub role
  • the resulting GitHub artifact shows the sub-agent’s mapped bot identity, not the parent’s

Desired outcome

Add a live e2e test that proves the following story:

As a parent synthetic OpenCode agent, when I delegate a GitHub-writing action to a different synthetic sub-agent, orfe resolves and uses the delegated sub-agent identity rather than my own.

Dependencies

Preconditions

The story must assume and require:

  • the orfe-e2e repository exists
  • orfe-e2e config exists and defines at least two mapped synthetic agents:
    • orfe-e2e-operator -> 0RF3-0P3R470R-BOT
    • orfe-e2e-author -> 0RF3-4U7H0R-BOT
  • both synthetic agents are available in the OpenCode runtime
  • a low-cost or free OpenCode model is configured for the synthetic e2e agents
  • a fixture issue exists in orfe-e2e that is safe for repeated comment-based testing, or the test creates one through a prerequisite step if that is the chosen fixture strategy
  • the run uses a unique run identifier
  • the test does not depend on artifacts created by prior runs except for approved reusable fixtures

Agent model for this story

This story should involve two different synthetic agents:

  • a parent agent: orfe-e2e-operator
  • a delegated sub-agent: orfe-e2e-author

The important distinction is:

  • the parent agent initiates the run and delegates the action
  • the sub-agent performs the actual orfe invocation
  • the resulting GitHub side effect must use the sub-agent’s mapped GitHub identity

Command under test

This story should exercise:

  • orfe issue comment

through the real OpenCode-integrated path.

The story must run through OpenCode and actual sub-agent delegation, not through direct core invocation.

Suggested test flow

  1. Generate a unique run id.
  2. Start the test through opencode run using orfe-e2e-operator as the parent agent.
  3. Have the parent agent delegate a task to orfe-e2e-author.
  4. Through the delegated sub-agent, invoke orfe issue comment on the chosen fixture issue with a body containing the run id and clear delegation markers.
  5. Capture the structured output from the command.
  6. Verify the resulting GitHub comment exists on the expected issue.
  7. Verify the visible GitHub actor identity is 0RF3-4U7H0R-BOT.
  8. Verify the visible actor identity is not 0RF3-0P3R470R-BOT.
  9. Apply the agreed cleanup/isolation policy from Define the live e2e test contract for orfe in orfe-e2e #31.

Required assertions

The test should explicitly assert all of the following:

OpenCode/runtime assertions

  • the run starts with orfe-e2e-operator as the parent agent
  • the write action is delegated to orfe-e2e-author
  • the orfe custom tool loads successfully in delegated execution
  • the delegated sub-agent caller name is the one resolved at the wrapper boundary
  • the parent agent caller identity is not incorrectly reused for the delegated orfe invocation

Tool output assertions

  • orfe issue comment exits successfully
  • the command emits valid structured JSON
  • returned JSON includes the expected issue reference and comment URL or equivalent comment metadata

GitHub artifact assertions

  • the expected comment exists on the target issue in orfe-e2e
  • the comment body includes the run id
  • the comment body is uniquely attributable to this test run

Actor identity assertions

  • the visible GitHub actor for the created comment is 0RF3-4U7H0R-BOT
  • the story fails if the visible actor is 0RF3-0P3R470R-BOT
  • the story fails if the actor identity is otherwise inconsistent with the configured delegated sub-agent mapping

Isolation assertions

  • the created comment is uniquely identifiable by run id
  • repeated runs do not depend on manual cleanup of prior comments to pass

Output / evidence requirements

The test should record enough evidence to debug failures, including:

  • run id
  • parent agent name
  • delegated sub-agent name
  • mapped GitHub role/bot for the delegated sub-agent
  • target issue number
  • created comment URL
  • observed visible actor identity used for validation

Cleanup / isolation

Follow the policy defined in #31.

If comments are retained rather than deleted, they must remain clearly tagged by run id.

Acceptance criteria

  • a live e2e test exists for delegated sub-agent caller identity propagation
  • the test runs through the OpenCode-integrated path
  • the test includes real parent -> sub-agent delegation
  • the test invokes orfe issue comment from the delegated sub-agent
  • the test proves the delegated sub-agent caller name is used by orfe
  • the test validates structured output from the command
  • the test validates the created GitHub comment in orfe-e2e
  • the test validates visible 0RF3-4U7H0R-BOT actor identity
  • the test validates that the parent agent’s bot identity was not used for the delegated write
  • the test follows the isolation policy from Define the live e2e test contract for orfe in orfe-e2e #31
  • the test is opt-in and not part of the default fast test path

Non-goals

  • validating production personas
  • validating broader multi-agent workflow orchestration
  • validating PR/project behavior in this issue
  • replacing the other command-specific e2e stories

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    Status
    Todo

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions