Files

3.1 KiB

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.