Implement e2e story: `orfe-e2e-operator` gets or creates a pull request through `orfe`

[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 lookup/create path for orfe-e2e PR management:

• 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 reads an existing PR when one already exists for the orfe-e2e branch/issue fixture
• orfe creates a PR when one does not already exist and then returns structured information about that PR

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 look up a pull request for a orfe-e2e branch and issue context and create that pull request when it does not already exist, and the resulting GitHub artifact reflects the expected PR identity, reuse-or-create behavior, and GitHub actor identity.

Dependencies

• Blocked by: Define the live e2e test contract for orfe in orfe-e2e #31
• Blocked by: Implement orfe pr get #20 (orfe pr get)
• Blocked by: Implement orfe pr get-or-create #26 (orfe pr get-or-create)
• builds on the orfe design/spec from Design the orfe custom tool and CLI contract #13

Preconditions

The story must assume and require:

• a dedicated orfe-e2e repository exists
• a orfe-e2e issue fixture exists for the run, or the test provisions one through an approved fixture path documented in the test
• a orfe-e2e branch fixture exists with committed content that is valid for PR creation against the chosen base branch
• the test documents precisely how the branch fixture is created, named, and isolated by run id
• the test documents whether it validates both the create path and the reuse path in one scenario or in separate scenarios
• if the reuse path is validated, an existing PR fixture for the same branch/issue context exists or is created deterministically earlier in the scenario
• 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 get-or-create

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 an issue fixture and branch fixture exist in the orfe-e2e repository with deterministic names/content for the run.
3. Invoke OpenCode with orfe-e2e-operator.
4. Through that agent, call orfe pr get for the prepared branch/issue context before PR creation and capture structured output.
5. Verify the command reports the expected absence or presence state according to the scenario design.
6. Through the same agent, call orfe pr get-or-create for the same branch/issue context.
7. Capture the structured output from the get-or-create command.
8. Verify the resulting PR on GitHub matches the expected branch, base, and issue linkage conventions for the scenario.
9. If the scenario validates reuse behavior, call orfe pr get or orfe pr get-or-create again and verify the same PR is reused rather than duplicated.
10. Verify the visible GitHub actor identity is 0RF3-0P3R470R-BOT where GitHub exposes it.
11. 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 get-or-create exits successfully
• all exercised commands emit valid structured JSON
• output includes the expected PR number and URL when a PR exists or is created
• output distinguishes clearly between not-found, created, and reused cases according to the command contract

GitHub artifact assertions

• the target PR exists in the orfe-e2e repository after the create path is exercised
• the PR head branch matches the prepared orfe-e2e branch fixture
• the PR base branch matches the documented test expectation
• the PR is associated with the intended orfe-e2e issue context if the command contract includes issue linkage
• if the scenario validates reuse behavior, the second retrieval returns the same PR number rather than creating a duplicate PR
• no unexpected duplicate PR is created for the same branch/issue context during the run

Actor identity assertions

• the visible GitHub actor for PR creation is 0RF3-0P3R470R-BOT where GitHub exposes it
• if the scenario exercises a reuse path only, the actor identity evidence strategy is documented for the original creation event used by the test
• the story should fail if the artifact appears to have been created by the wrong bot identity

Isolation assertions

• the branch fixture and any PR artifacts are uniquely identifiable by run id
• the run does not require prior manual cleanup to pass
• the branch fixture strategy is documented precisely enough that repeated runs remain deterministic and do not accidentally collide with prior orfe-e2e PRs

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
• issue number if applicable
• branch name
• base branch name
• initial pr get result
• resulting PR number
• resulting PR URL
• whether the command path was create or reuse
• 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 PR, issue, and branch artifacts must remain clearly attributable to the test run id
• the test documentation must state whether retained PRs are expected to stay open or be closed after validation
• the retained branch/PR strategy must avoid collisions with later runs

Acceptance criteria

• a live e2e test exists for the orfe-e2e-operator PR get/get-or-create 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 get-or-create
• the test validates structured output for both exercised commands
• the test validates the resulting GitHub PR state in the orfe-e2e repository
• the test validates create-or-reuse behavior without ambiguous duplicate PRs
• 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

• workflow comment validation
• project status validation
• PR comment or PR review behavior
• testing production persona definitions
• testing broader multi-agent orchestration behavior
• validating arbitrary branch management outside the fixture setup needed for this story