Skip to content

Implement e2e story: orfe-e2e-operator comments on a pull request through orfe #36

Description

@z0r4n-bot

Context

Issue #31 defines the live e2e contract for orfe in orfe-e2e.

This story should validate a real OpenCode-integrated pull request comment path for orfe-e2e PR collaboration:

  • the OpenCode custom tool loads
  • context.agent is available
  • the wrapper passes caller identity into orfe
  • orfe-e2e repo config maps that caller name to the correct GitHub App identity
  • orfe posts a real comment on a orfe-e2e pull request through the live GitHub API

This story should use orfe-e2e-operator, not a production persona.

Desired outcome

Add a live e2e test that proves the following story:

As orfe-e2e-operator, I can invoke orfe through OpenCode to post a comment on a orfe-e2e pull request, and the resulting GitHub artifact reflects the expected comment content, target PR identity, and GitHub actor identity.

Dependencies

Preconditions

The story must assume and require:

  • a dedicated orfe-e2e repository exists
  • a orfe-e2e pull request fixture exists for the run, or the test provisions one through an approved fixture path documented in the test
  • the fixture PR is in a commentable state and remains accessible for the duration of the test
  • the test documents precisely how the PR fixture is created, identified, and isolated by run id
  • orfe-e2e orfe config exists and points at the orfe-e2e repository
  • orfe-e2e orfe config defines the orfe-e2e-operator caller name mapped to the 0RF3-0P3R470R-BOT GitHub App identity
  • a low-cost or free OpenCode model is configured for orfe-e2e-operator
  • 0RF3-0P3R470R-BOT is installed and authorized for the orfe-e2e repository
  • the e2e run uses a unique run identifier
  • the test does not depend on artifacts created by prior runs except for explicitly documented reusable orfe-e2e infrastructure

Agent model for this story

This story should use the orfe-e2e-operator synthetic e2e agent defined only for orfe-e2e use.

The test must not depend on the production Jelena persona definition.

What matters here is:

  • OpenCode passes orfe-e2e-operator through context.agent
  • orfe-e2e config maps that caller name to the 0RF3-0P3R470R-BOT GitHub App identity
  • orfe executes under the correct dedicated e2e GitHub App identity

Commands under test

The story should exercise these orfe commands through the real OpenCode-integrated path:

  1. orfe pr get
  2. orfe pr comment

The story must run through OpenCode, not by calling the orfe core directly.

Suggested test flow

  1. Generate a unique run id for the test.
  2. Ensure a orfe-e2e PR fixture exists and is uniquely attributable to the run.
  3. Invoke OpenCode with orfe-e2e-operator.
  4. Through that agent, call orfe pr get for the fixture PR context and capture structured output.
  5. Verify the read output identifies the intended PR fixture.
  6. Through the same agent, call orfe pr comment with a comment body containing the run id and deterministic content.
  7. Capture the structured output from the comment command.
  8. Verify the resulting PR comment on GitHub matches the expected body and is attached to the intended PR.
  9. Verify the visible GitHub actor identity is 0RF3-0P3R470R-BOT where GitHub exposes it.
  10. 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 test runs through OpenCode, not a direct core-only path
  • the orfe custom tool loads successfully
  • orfe-e2e-operator is the caller name used at runtime
  • the configured caller-name → GitHub App identity mapping is exercised successfully

CLI / tool output assertions

  • orfe pr get exits successfully
  • orfe pr comment exits successfully
  • all exercised commands emit valid structured JSON
  • read output includes the expected PR number and URL
  • comment output includes the expected comment identifier and URL where the command contract exposes them

GitHub artifact assertions

  • the target PR exists in the orfe-e2e repository
  • the created comment exists on that PR
  • the comment body matches the expected deterministic content including the run id
  • the comment is attached to the intended PR and not a different artifact

Actor identity assertions

  • the visible GitHub actor for the PR comment is 0RF3-0P3R470R-BOT where GitHub exposes it
  • the story should fail if the artifact appears to have been created by the wrong bot identity

Isolation assertions

  • the PR fixture and created comment are uniquely identifiable by run id
  • the run does not require prior manual cleanup to pass
  • the chosen fixture strategy is documented precisely enough that repeated runs remain deterministic

Output / evidence requirements

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

  • run id
  • synthetic caller name used for the run
  • mapped GitHub App identity
  • PR number
  • PR URL
  • comment URL
  • final observed comment body
  • observed actor identity fields used for validation

Cleanup / isolation

Follow the policy defined in #31.

If the chosen policy is retention instead of deletion:

  • the retained comment must remain clearly attributable to the test run id
  • the retained PR fixture must remain distinguishable from human-created orfe-e2e activity
  • the policy must document whether comment retention is intentional evidence or whether PR fixtures are rotated/reset outside the test

Acceptance criteria

  • a live e2e test exists for the orfe-e2e-operator PR comment story
  • the test runs through the OpenCode-integrated path
  • the test uses orfe-e2e-operator, not a production persona
  • the test proves caller-name resolution through context.agent
  • the test proves caller-name → GitHub App identity mapping for orfe-e2e-operator
  • the test invokes orfe pr get
  • the test invokes orfe pr comment
  • the test validates structured output for both exercised commands
  • the test validates the final PR comment artifact in the orfe-e2e repository
  • the test validates visible 0RF3-0P3R470R-BOT actor identity where relevant
  • the test follows the orfe-e2e 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

  • PR creation behavior beyond the fixture setup needed for this story
  • workflow comment validation
  • project status validation
  • PR review submission or reply behavior
  • testing production persona definitions
  • testing broader multi-agent orchestration behavior

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