Hop
b04e24a543
Hop-State: A_06FN6X5SEFS9VB6A92K2JE0 Hop-Proposal: R_06FN6X45KVCRM0P2G9SF9N0 Hop-Task: T_06FN6Q6CPY9NYPA25F6DKS8 Hop-Attempt: AT_06FN6WXQF509ZK786R6N7Z0
67 lines
2.6 KiB
Markdown
67 lines
2.6 KiB
Markdown
# 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 repository **Prompts** view is the review surface for that causal record:
|
|
the requested work, agent identity and runtime metadata, response summary, and
|
|
links to the task, attempt, and immutable state that produced it.
|
|
|
|
Hop automatically writes immutable, portable prompt records to
|
|
`.hop/records/prompts/` when it creates a proposal. Git tracks those records
|
|
with the code, while Hop's local database and disposable workspaces remain
|
|
ignored. Run `make hop-records` to export the complete local record history on
|
|
demand.
|
|
|
|
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](docs/product-blueprint.md) and
|
|
[the Gitea foundation decision](docs/adr/0001-gitea-as-forge-foundation.md).
|
|
|
|
## 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.
|