Skip to content

Define provider-neutral planning pull request foundations #184

Description

@rochecompaan

Part of #180.

Goal

Create the stable, provider-neutral modules that later planning pull request work can implement and consume. This is the first delivery slice for #180.

Scope

  • Define canonical repository and pull request types, errors, and the host interface.
  • Define the pure phase planner for all four spec and plan gate combinations.
  • Define planning pull request markers, titles, and body conventions.
  • Define the planning workspace lifecycle interface and snapshots.
  • Add contract tests with fake host and workspace adapters.

Out of scope

  • GitHub and Forgejo commands.
  • Git worktree implementation.
  • Persistent run state, agents, publication, or pipeline wiring.
  • Production provider stubs that throw “not implemented.”

Acceptance criteria

  • The provider-neutral pull request interface documents identity, completeness, and error semantics.
  • The phase planner covers all four gate combinations with behavior tests.
  • The workspace interface hides Git command sequencing behind high-level lifecycle operations.
  • Fake adapters compile against the same interfaces later production adapters will use.
  • Existing runtime behavior is unchanged.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    agent-doneIssue was completed by automationplan-approvedImplementation plan approved for automationspec-approvedSpecification approved for automation

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions