# Hop-native Gitea semantics

HopWeb keeps Gitea's existing forge interface and adds a Hop-specific public
home page, brand mark, and semantic vocabulary for collaboration elements.

## Install

From the project root:

```sh
./deploy/gitea/install-hop-native.sh
```

Set `ENV_FILE` when the Compose environment is stored elsewhere:

```sh
ENV_FILE=/path/to/environment ./deploy/gitea/install-hop-native.sh
```

The installer copies the home page, brand mark, styles, and adapter into
Gitea's persistent custom directory, sets the application name to `Hop`,
restarts Gitea, and waits for a healthy response. Re-run it after editing an
asset or replacing the Gitea volume.

## Semantic mapping

| Native route and behavior | Hop label |
| --- | --- |
| Repository code | Files |
| — | Prompts (Hop-native causal record) |
| Issues | Tasks |
| Branches | Attempts |
| Commits | Checkpoints |
| Pull requests | Proposals |
| Actions | Evidence |
| Merge pull request | Accept proposal |

The adapter updates visible text, document titles, form placeholders,
tooltips, and ARIA labels. It scopes replacements to Gitea navigation,
headings, menus, breadcrumbs, labels, and buttons, so repository content and
user-authored prose remain unchanged.

Repository home pages also receive a `Hop workflow` group in the existing
Gitea sidebar. It uses Gitea's own classes, links, icons, and live counts.

## Private prompt history

The Prompts tab reads from the Hop control plane. The browser's Gitea session
identifies the viewer, repository authorization is checked, and the database
query is scoped to that viewer's immutable Gitea user ID. Unowned legacy rows
are excluded. The UI never reads `.hop/records/prompts/` from a Git branch:
repository-wide portable records cannot enforce a per-user privacy boundary.

Local Hop exports can contain prompts and machine paths. `.hop/` is ignored and
must not be committed or served by the forge.

## Upgrade check

After changing the pinned Gitea version:

1. run the installer;
2. confirm Prompts, Tasks, Proposals, and Evidence in repository navigation;
3. confirm Attempts and Checkpoints in the Files view;
4. confirm proposal creation and acceptance labels;
5. inspect browser console errors; and
6. test a narrow viewport and keyboard navigation.