Feature Recommendation Report: Scope Safety and Validation Improvements

Feature Recommendation Report: Scope Safety and Validation Improvements

Summary

Hetty's scope system is an important safety boundary for deciding which traffic should be considered relevant, captured, or acted on. Because scope rules can directly influence operator visibility and workflow safety, the product would benefit from stronger validation, observability, and change tracking around scope configuration.

This report recommends four features that would improve scope reliability and reduce the risk of silent misconfiguration:

• a scope preview/tester
• a read-back view for effective scope configuration
• validation for suspicious key/value regex duplication
• audit logs for scope changes

These features are especially valuable in a proxy and interception tool where users may depend on scope to avoid collecting or acting on unintended traffic.

Goals

The main goals of these features are:

• help users verify scope behavior before committing changes
• make the applied scope configuration transparent
• detect likely configuration mistakes early
• provide accountability and history for scope changes

Together, these features reduce both user error and the impact of implementation bugs in scope handling.

Feature 1: Scope Preview / Tester

Problem

Today, a user can define a scope rule, but there is limited immediate feedback about whether the rule will match the traffic they actually care about.

With regex-based URL, header, and body matching, even small mistakes can lead to:

• overly broad scope
• overly narrow scope
• false assumptions about what traffic will be captured

Proposed Feature

Add a scope preview/tester that lets users validate whether a request would match a scope rule before saving it.

User Experience

The UI could provide:

• a form where users enter a sample URL
• optional HTTP method
• sample headers
• optional sample body
• the proposed scope rule

Then Hetty would show:

• whether the request matches the rule
• which part of the rule matched
• which parts did not match
• a human-readable explanation of the decision

API Support

Add a GraphQL field or mutation such as:

testScopeRule(input: ScopeRuleInput!, request: ScopeTestRequestInput!): ScopeTestResult!

Example result fields:

• matches: Boolean!
• matchedFields: [String!]!
• failedFields: [String!]!
• explanation: String

Benefits

• reduces accidental misconfiguration
• makes regex-based rules easier to understand
• improves trust in scope behavior
• helps users debug why a rule is or is not working

Suggested Enhancements

• test against a saved request log entry
• test against an intercepted request
• batch preview against the last N requests
• show how many stored requests would match before applying the rule

Feature 2: Read-Back Effective Scope Configuration View

Problem

Users need a reliable way to confirm what scope configuration is actually active after saving it.

This matters because:

• UI input may not reflect stored state exactly
• serialization/deserialization issues can alter rules
• implementation bugs can change effective behavior
• users may want to review active rules later without reconstructing their original intent