Skip to content

Add a code-forge provider for repository bootstrap #33

Description

@danielblignaut

Outcome

Replace openbot init's temporary direct gh repository orchestration with a narrow code-forge/Git provider boundary, implementing GitHub first.

ADR-0013 in #8 defines the repository-bootstrap contract. This issue is distinct from #14: #14 covers mutable agent repository workspaces and publication workflows; this issue covers owner repository provisioning during installation.

Scope

  • Define the provider contract in the owning provider package under src/core.ts or src/core/index.ts.
  • Model forge account/owner discovery, repository availability, visibility, public fork creation, private mirror destination creation, clone URLs, default-branch metadata, and authentication handoff.
  • Implement GitHub using typed gh command-runner operations; keep GitLab/Bitbucket out until real requirements exist.
  • Inject GUI-neutral init questions/choices without coupling the provider to Ink.
  • Refactor init so provider output drives origin/upstream setup while local clone, mirror, cleanup, and Git history operations remain application workflow.
  • Preserve the ADR-0013 empty-directory, private-default, fail-before-configuration, and temporary-directory cleanup guarantees.
  • Never put forge credentials in command arguments, remotes, generated files, logs, or provider outputs.

Architecture boundary

flowchart LR
  I["openbot init workflow"] --> P["Git provider"]
  P --> G["GitHub repository APIs through gh"]
  I --> L["Local git clone / mirror / remotes"]
  P --> L
Loading

The provider owns forge-specific repository operations. The CLI owns local Git mechanics. It must not become a generic shell, filesystem, or repository-workspace provider.

Acceptance criteria

  • Public init provisions a real GitHub fork with the requested name.
  • Private init provisions an independent private mirror with the requested name.
  • origin is the owner repository and upstream is canonical OpenBot.
  • Missing/unauthenticated provider tooling fails before SOPS or configuration mutation.
  • Provider questions remain renderer-agnostic.
  • Temporary bare repositories are securely created and cleaned after success or failure.
  • Focused provider contract tests cover public, private, existing-repository, auth-failure, and cleanup paths.
  • README and provider-authoring documentation describe the public API and ownership boundary.

Related

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

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions