Add a no-redesign semantic layer that makes native Gitea collaboration Hop-first
Hop-State: A_06FN45YJ09WC2QFGJM27VE8 Hop-Proposal: R_06FN45WVVTHC245S2BK503G Hop-Task: T_06FN3MVGY3MT82ESQ89BND0 Hop-Attempt: AT_06FN3MVGY092BFA5MR9C7EG
This commit is contained in:
@@ -0,0 +1,55 @@
|
||||
# Hop-native Gitea semantics
|
||||
|
||||
HopWeb keeps Gitea's existing interface design and changes the meaning of its
|
||||
collaboration elements. No custom stylesheet, theme, component library, or
|
||||
layout override is installed.
|
||||
|
||||
## 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 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 the adapter or replacing the Gitea volume.
|
||||
|
||||
## Semantic mapping
|
||||
|
||||
| Native route and behavior | Hop label |
|
||||
| --- | --- |
|
||||
| Repository code | Files |
|
||||
| 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.
|
||||
|
||||
## Upgrade check
|
||||
|
||||
After changing the pinned Gitea version:
|
||||
|
||||
1. run the installer;
|
||||
2. confirm 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.
|
||||
|
||||
Reference in New Issue
Block a user