19 lines
1.5 KiB
Markdown
19 lines
1.5 KiB
Markdown
# 01 — Create and activate persistent Proxy Profiles
|
|
|
|
**What to build:** A runnable `proxyctl` TUI in which a user can manage validated Proxy Profiles and select an Active Profile, establishing the first complete path from keyboard interaction through the Application Module to durable configuration.
|
|
|
|
**Blocked by:** None — can start immediately.
|
|
|
|
**Status:** done
|
|
|
|
- [ ] Running `proxyctl` without arguments opens a keyboard-driven TUI and shows the Active Profile or a clear no-Profile state.
|
|
- [ ] The Profile page lets the user create, view, edit, delete, and activate uniquely named Proxy Profiles.
|
|
- [ ] Single proxy mode accepts one URL and expands it for compatible protocol uses without losing the user's value when advanced editing is opened.
|
|
- [ ] Advanced mode supports distinct HTTP, HTTPS, and ALL/SOCKS URLs.
|
|
- [ ] URL validation accepts only HTTP, HTTPS, SOCKS5, and SOCKS5H with valid hosts and ports and presents actionable validation errors.
|
|
- [ ] Bypass validation accepts exact hostnames, domain suffixes, IPv4, IPv6, and CIDR, then normalizes and deduplicates entries.
|
|
- [ ] No Profile is guessed or created automatically; the main page remains accessible when no Active Profile exists.
|
|
- [ ] Profile configuration follows XDG conventions, is written atomically, and is restricted to the owning user.
|
|
- [ ] Proxy passwords are obscured in rendered output and redacted from all errors produced by this slice.
|
|
- [ ] Application-level tests drive Profile behavior through the Interface consumed by the TUI rather than private helpers.
|