Files
GitHop/README.md
T
Hop dd2c0abfd2 Define HopWeb as a prompt-native forge built on a maintainable Gitea foundation
Hop-State: A_06FN3NFQ6P95HFKCSC22JMR
Hop-Proposal: R_06FN3NF43ARPM6SBXX0F15R
Hop-Task: T_06FN3MVGY3MT82ESQ89BND0
Hop-Attempt: AT_06FN3MVGY092BFA5MR9C7EG
2026-07-11 08:40:04 -07:00

2.1 KiB

HopWeb

HopWeb is a collaborative forge for prompt-native software development.

It uses Git for durable source storage and Gitea for the proven forge substrate, but makes Hop's workflow the primary product model:

  • a task captures the outcome someone wants;
  • a prompt state records each instruction in its causal context;
  • an attempt is an isolated line of human or agent work;
  • a checkpoint freezes the exact tree that was evaluated;
  • evidence records checks against that immutable checkpoint;
  • a proposal is a reviewable candidate outcome; and
  • an accepted state is the current shared truth.

The product thesis is simple:

GitHub organizes collaboration around commits and pull requests. HopWeb organizes human-agent collaboration around intent, attempts, evidence, and accepted outcomes.

Foundation

Gitea supplies the expensive, mature infrastructure we should not rebuild:

  • Git transport, repositories, LFS, and permissions
  • users, organizations, teams, OAuth, and access tokens
  • issues, notifications, webhooks, releases, packages, and Actions
  • administration, audit surfaces, and deployment primitives

Hop supplies the differentiating control plane and experience:

  • prompt and state graph persistence
  • task and attempt orchestration
  • agent identity and attribution
  • checkpoint-bound validation evidence
  • proposal review and acceptance semantics
  • a Hop-native repository, task, attempt, and review interface

See the product blueprint and the Gitea foundation decision.

First release

The first useful release is not a complete GitHub clone. It is a private, single-installation forge where a user can:

  1. create or import a repository;
  2. open a task with a prompt;
  3. launch one or more isolated agent attempts;
  4. watch states, diffs, and checks appear live;
  5. compare proposals by outcome and evidence; and
  6. accept one proposal into the repository's shared state.

Everything else should be inherited from Gitea until the Hop workflow proves that it needs a different abstraction.