Hop
8115847b32
Hop-State: A_06FN45YJ09WC2QFGJM27VE8 Hop-Proposal: R_06FN45WVVTHC245S2BK503G Hop-Task: T_06FN3MVGY3MT82ESQ89BND0 Hop-Attempt: AT_06FN3MVGY092BFA5MR9C7EG
72 lines
3.1 KiB
Markdown
72 lines
3.1 KiB
Markdown
# HopWeb Product
|
|
|
|
## Register
|
|
|
|
product
|
|
|
|
## Users
|
|
|
|
HopWeb is designed first for solo software developers who direct multiple AI
|
|
agents and need to understand, compare, and trust their work without manually
|
|
reconstructing intent from terminals and commit histories. The product should
|
|
also support engineering teams reviewing agent-produced outcomes, with clear
|
|
human ownership, attribution, policy, and evidence.
|
|
|
|
Users arrive with an outcome in mind. Their primary workflow is to state that
|
|
outcome, launch or supervise isolated attempts, intervene when necessary,
|
|
compare proposals, inspect evidence, and accept one verified result as shared
|
|
truth.
|
|
|
|
## Product Purpose
|
|
|
|
HopWeb is a prompt-native software forge. It combines universal Git
|
|
compatibility with a causal record of requested intent, agent attempts,
|
|
immutable checkpoints, validation evidence, reviewable proposals, and accepted
|
|
outcomes.
|
|
|
|
Success means a developer can answer four questions immediately: what was
|
|
requested, who or what attempted it, what exact result was verified, and which
|
|
outcome became accepted truth. Git files, commits, branches, and pull requests
|
|
remain available as compatibility views, but they do not dictate the primary
|
|
experience.
|
|
|
|
## Brand Personality
|
|
|
|
Focused, assured, and alive.
|
|
|
|
HopWeb should feel fast and command-ready like a serious developer instrument,
|
|
while remaining calm enough for careful review. Its personality comes from the
|
|
clarity of the state model and the visible motion of work through that model,
|
|
not decorative futurism or AI theatrics.
|
|
|
|
## Anti-references
|
|
|
|
- Not Gitea with an AI sidebar or a chatbot pasted onto repository pages.
|
|
- Not a generic SaaS dashboard assembled from interchangeable metric cards.
|
|
- Not a noisy cyberpunk developer tool with neon-on-black styling.
|
|
- Not an opaque agent console that asks users to trust summaries without exact
|
|
diffs and checkpoint-bound evidence.
|
|
- Not a GitHub imitation that merely renames pull requests and branches.
|
|
|
|
## Design Principles
|
|
|
|
1. **Intent before implementation.** Lead with the requested outcome and its
|
|
causal context before files, commits, or activity feeds.
|
|
2. **Supervision at a glance.** Make active attempts, interventions, failures,
|
|
and acceptance readiness legible without opening every detail view.
|
|
3. **Evidence is attached, not implied.** Every claim of success points to the
|
|
immutable checkpoint and checks that support it.
|
|
4. **Progressive Git compatibility.** Keep familiar Git affordances close, but
|
|
let Hop concepts own hierarchy, naming, and default navigation.
|
|
5. **Density without anxiety.** Favor keyboard speed and information density
|
|
while preserving rhythm, clear priority, and calm review states.
|
|
|
|
## Accessibility & Inclusion
|
|
|
|
Target WCAG 2.2 AA. Every workflow must be fully keyboard operable with visible
|
|
focus, semantic landmarks, descriptive labels, and non-color status cues.
|
|
Respect reduced-motion preferences and preserve comprehension when motion is
|
|
disabled. Status palettes must remain distinguishable for common color-vision
|
|
differences, and dense views must support comfortable zoom and narrow screens.
|
|
|