20 lines
1.4 KiB
Markdown
20 lines
1.4 KiB
Markdown
# 09 — Attach Protocol Probe to the Profile field
|
|
|
|
**What to build:** Make Protocol Probe an explicit, user-initiated URL-field action whose progress and result remain attached to the input that produced them.
|
|
|
|
**Blocked by:** 08 — Deliver the mature Profile editor.
|
|
|
|
**Status:** done
|
|
|
|
- [x] The applicable URL field visibly offers Protocol Probe and documents its keyboard shortcut.
|
|
- [x] Probe never runs when the form opens, when focus changes, or when a Profile is saved.
|
|
- [x] Progress, endpoint-safe status, and detected capabilities render with the initiating field rather than as unrelated global status.
|
|
- [x] HTTP-only detection populates the established HTTP representation.
|
|
- [x] SOCKS5-only detection preserves the established `socks5h` semantics.
|
|
- [x] Dual HTTP/SOCKS5 detection creates the established compatible Advanced Profile values.
|
|
- [x] Editing the relevant URL, changing mode, saving, or cancelling invalidates an in-flight result.
|
|
- [x] Repeated invocation while the same probe is active does not start duplicate work.
|
|
- [x] Userinfo and credentials never appear in dial evidence, status, errors, or rendered frames.
|
|
- [x] Failure and unrecognized-protocol results leave user input editable and do not prevent saving a manually chosen value.
|
|
- [x] Complete-Model tests cover all capabilities, failure, explicit invocation, no hidden network work, duplicate suppression, resize, and every stale-result path.
|