Configurator: guided firewall policy editor and Assistant rule/NAT proposals (post-MVP) #101

Scope decision (2026-10-13)

Explicitly outside the Configurator MVP. The MVP may provision firewall infrastructure/HA while a firewall administrator configures and maintains the traffic policy afterwards. Infrastructure/HA is not proof of isolation, internet access, NAT or configured firewall rules. No automatic permissive baseline is implied.

Current capability and gap

• The native Accelerator supports the single-appliance firewall_config contract: aliases, routes, rules, outbound NAT and port forwards, including explicit HA policy synchronization.
• The common Configurator editor already exposes that contract through generic fields under Operations / Firewall rules. This is not a guided or fully qualified policy-management workflow; legacy editor surfaces must be assessed separately.
• The Assistant cannot define or accept firewall policy changes. Traffic/policy statements in chat are requirements, not configured rules. It must disclose this boundary immediately instead of continuing a questionnaire that promises rule proposals.
• This issue must not be confused with Automate firewall policies for multiple appliances #65, which extends native policy distribution to multiple appliances.

Future implementation

• Provide a discoverable guided policy editor with explicit interface, source/destination, ports/protocol, action/direction, ordering and enable/log settings; retain compatible generic import/export.
• Model aliases, routes/gateways, outbound NAT and inbound port forwards consistently with the reviewed native contract; reject unresolved references and incompatible dependencies.
• Implement bounded, evidence-backed Assistant proposals and a per-field/per-rule diff with explicit acceptance, conflict handling and separate saving. Preserve existing/unmanaged settings; no inferred allow-any or automatic replacements.
• Define ownership and coexistence with firewall-admin changes, deletion semantics, ordering and transitions from manually managed policy. A Terraform state/import and reconciliation strategy is required before takeover.
• Keep API credentials outside chat/configuration documents; qualify endpoint/TLS, bootstrap, private runner reachability and explicit HA synchronization separately.
• Review the single-appliance limitation; multi-appliance support depends on Automate firewall policies for multiple appliances #65 and must not be implied.

Acceptance criteria

• Desktop/mobile editor round trips and native exports preserve unrelated policy and infrastructure, including omitted/null/default distinctions.
• Assistant regression tests cover existing rules, missing targets/interfaces, aliases/gateways, ordering conflicts, rejected broad rules, policy deletion and unsupported multi-appliance scope.
• Compiler, authorization, revision/conflict and secret-boundary tests cover both entry points; no model-generated HCL or autonomous execution.
• Plan/Apply is separately authorized and qualified; packet-path tests prove allowed/denied traffic and NAT where claims are made. Same-subnet traffic and HA/public-IP limits remain explicit.
• Until qualified, UI and chat clearly distinguish native capability, editable drafts and executable policy, with firewall-admin handover as the MVP alternative.

Related: #89 (supported execution), #94 (bounded Assistant), #65 (native multi-appliance policies).

This is a future enhancement, not an MVP acceptance gate or a permission to apply firewall changes.