Charon/docs/plans/current_spec.md

QA Audit Remediation Plan: DNS Provider E2E Test Fixes

Executive Summary

Date: February 1, 2026 Source: QA Audit Report (docs/reports/qa_report_dns_provider_e2e_fixes.md) Status: 🔴 CRITICAL - 3 Blocking Issues Require Resolution Approval Gate: Must resolve Issues 1 & 2 before merge approval Planning Agent: Principal Architect (Planning Mode) Confidence Score: 90% (High Confidence - Clear requirements, established patterns)

This plan addresses three critical issues identified during comprehensive QA audit:

1. E2E Firefox Test Instability (CRITICAL - BLOCKS MERGE)
2. Backend Coverage 24.7% (CRITICAL - BLOCKS MERGE)
3. Docker Image 7 HIGH CVEs (HIGH - REQUIRES DOCUMENTATION)

Classification: Multi-Phase Remediation - Test stability fixes, coverage verification, and security documentation.

Original CI Job: https://github.com/Wikid82/Charon/actions/runs/21558579945/job/62119064955?pr=583

---

Phase 1: ANALYZE

Requirements (EARS Notation)

REQ-1: Firefox E2E Test Stability (CRITICAL)

• WHEN a Playwright E2E test selects Webhook or RFC2136 provider type, THE SYSTEM SHALL reliably wait for the "Credentials" section to appear before asserting field visibility
• WHEN running 10 consecutive Firefox tests, THE SYSTEM SHALL pass all tests without timeout failures
• IF a test waits for the "Credentials" section, THEN THE SYSTEM SHALL use a data-testid attribute with a timeout of at least 10 seconds to accommodate slower Firefox rendering

REQ-2: Backend Coverage Verification (CRITICAL)

• WHEN backend tests are executed with coverage enabled, THE SYSTEM SHALL generate coverage ≥85% total after excluding infrastructure packages
• WHEN coverage is measured, THE SYSTEM SHALL use fresh test data from current code state, not stale coverage files
• IF coverage is below 85%, THEN THE SYSTEM SHALL identify specific uncovered packages and functions for targeted test addition

REQ-3: Docker Security Documentation (HIGH)

• WHEN 7 HIGH severity CVEs are detected in base OS libraries, THE SYSTEM SHALL document risk acceptance with justification
• WHEN CVEs have no patches available, THE SYSTEM SHALL establish monitoring process for Debian security advisories
• WHERE Docker image is deployed, THE SYSTEM SHALL communicate risk to stakeholders and security team

Confidence Score: 90%

Rationale:

• ✅ Clear Requirements: QA report provides specific error messages, file paths, and recommendations
• ✅ Established Patterns: Similar test fixes exist in codebase (e.g., wait for network idle, semantic locators)
• ✅ Tooling Available: Backend coverage skill, E2E rebuild skill, and testing protocols documented
• ⚠️ Coverage Unknown: Backend coverage of 24.7% may be stale; requires verification before proceeding
• ✅ Risk Assessment: CVE impact analysis provided in QA report with mitigation factors

Execution Strategy: High Confidence → Proceed with comprehensive plan, skip PoC phase.

---

Phase 2: DESIGN

Technical Specifications

Issue 1: Firefox E2E Test Instability

Root Cause Analysis (per Supervisor Review):

1. Element Type: "Credentials" is a <Label> at line 209 in DNSProviderForm.tsx, NOT a heading
2. Current Locator: Test uses page.getByText(/^credentials$/i) (correct)
3. Timing Issue: React rendering slower in Firefox, causing 5-second timeout to expire
4. Browser-Specific: Only affects Firefox (0/10 failures in Chromium/WebKit)
5. Root Cause: Timeout too short, not selector issue

Failed Tests:

• tests/dns-provider-types.spec.ts - RFC2136 server field (3 failures in Firefox)
• tests/dns-provider-types.spec.ts - Webhook URL field (1 failure in Firefox)

Error Pattern:

TimeoutError: locator.waitFor: Timeout 5000ms exceeded.
Call log:
  - waiting for getByText(/^credentials$/i) to be visible

Design Decision: Implement Option C (Supervisor Recommended) - Add data-testid attribute for robust testing

Rationale:

• Best Practice: Test-specific attributes are more stable than text-based locators
• Immune to Translations: Won't break if translation keys change
• Performance: Direct DOM query faster than text regex matching
• Timeout: Increase to 10 seconds to accommodate Firefox rendering
• Maintainability: Explicit test hooks document testable elements

API Design: Two-Part Implementation

Part 1: Frontend Component Update

// In DNSProviderForm.tsx (line ~209)
<Label data-testid="credentials-section">
  {t('dnsProviders.credentials')}
</Label>

Part 2: Test Helper Function

/**
 * Waits for DNS provider form credentials section to fully load.
 * Uses data-testid for stable, translation-independent selection.
 *
 * @param page - Playwright page object
 * @throws TimeoutError if credentials section not visible within 10 seconds
 */
async function waitForCredentialsSection(page: Page): Promise<void> {
  await page.locator('[data-testid="credentials-section"]').waitFor({
    state: 'visible',
    timeout: 10000  // Increased for Firefox compatibility
  });
}

Data Flow:

1. User/Test selects provider type from dropdown
2. React Query fetches /api/v1/dns-providers/types
3. State updates trigger re-render
4. DNSProviderForm.tsx renders "Credentials" label with data-testid (line 209)
5. Dynamic fields render based on provider type
6. Test waits for data-testid → asserts field visibility

Error Handling:

• Timeout: If section not visible after 10s, TimeoutError with clear message
• Stability: data-testid immune to translation changes
• Logging: Use Playwright trace for debugging future failures

---

Issue 2: Backend Coverage Verification

Root Cause Analysis (per QA Report):

1. Stale Data: Coverage file (coverage.out) may be outdated from previous run
2. Incomplete Test Run: Test suite may not have run completely during audit
3. Filtered Packages: Excludes infrastructure code per .codecov.yml

Current State:

• Reported: 24.7% coverage
• Threshold: 85%
• Gap: -60.3%

Design Decision: Run fresh coverage analysis with filtered packages

Execution Plan:

1. Delete stale coverage file: rm backend/coverage.out backend/coverage.txt
2. Run coverage skill: .github/skills/scripts/skill-runner.sh test-backend-coverage
3. Verify output matches threshold: go tool cover -func=backend/coverage.txt | grep total
4. If below 85%, generate HTML report and identify gaps

Expected Outcome:

• Scenario A: Coverage ≥85% → Stale data confirmed, no code changes needed
• Scenario B: Coverage <85% → Add targeted tests for uncovered packages

Packages Excluded from Coverage (per .codecov.yml and coverage skill):

• backend/cmd/api - Main entry points
• backend/cmd/seed - Database seeding tool
• backend/internal/logger - Logging infrastructure
• backend/internal/metrics - Metrics infrastructure
• backend/internal/trace - Tracing infrastructure
• backend/integration - Integration test utilities
• backend/pkg/dnsprovider/builtin - External DNS provider plugins

Coverage Validation:

# Step 1: Clean stale data
cd backend
rm -f coverage.out coverage.txt

# Step 2: Run tests with coverage
.github/skills/scripts/skill-runner.sh test-backend-coverage

# Step 3: Verify total coverage
go tool cover -func=coverage.txt | tail -1

# Step 4: Generate HTML report if needed
go tool cover -html=coverage.txt -o coverage.html

---

Issue 3: Docker Image CVE Documentation

Vulnerability Summary (per Grype scan):

• Total: 409 vulnerabilities
• Critical: 0
• High: 7 (requires documentation)
• Medium: 20
• Low: 2
• Negligible: 380

HIGH Severity CVEs Requiring Documentation:

CVE	Package	CVSS	Fix Available	Description
CVE-2026-0861	libc-bin, libc6	8.4	❌ No	Heap overflow in memalign functions
CVE-2025-13151	libtasn1-6	7.5	❌ No	Stack buffer overflow
CVE-2025-15281	libc-bin, libc6	7.5	❌ No	wordexp WRDE_REUSE issue
CVE-2026-0915	libc-bin, libc6	7.5	❌ No	getnetbyaddr nsswitch.conf issue

Risk Assessment:

• Exploitability: LOW - Requires specific function calls and attack conditions
• Container Context: MEDIUM - Limited attack surface in containerized environment
• Application Impact: LOW - Charon does not directly call vulnerable functions
• Compliance: HIGH - May flag in security audits

Design Decision: Create Security Advisory with Risk Acceptance

Document Structure:

# Security Advisory: Docker Base Image Vulnerabilities
## Summary
- 7 HIGH severity CVEs in Debian Trixie base image
- All CVEs affect system-level C libraries (glibc, libtasn1)
- No patches available from Debian as of February 1, 2026

## Risk Acceptance Justification
- Container isolation limits attack surface
- Application does not directly use vulnerable functions
- Monitoring plan established for Debian security updates

## Mitigation Factors
- Read-only filesystem in production
- Non-root user execution
- Network policy restrictions
- Regular security scanning in CI

## Monitoring Plan
- Weekly Grype scans to detect patch availability
- Subscribed to security-announce@lists.debian.org
- Automated PRs for base image updates

Acceptance Criteria:

• Security team review and approval documented
• Risk acceptance signed off by Tech Lead
• Monitoring process verified in CI

---

Component Interactions

graph TD
    A[QA Audit Report] --> B[Issue 1: E2E Firefox Tests]
    A --> C[Issue 2: Backend Coverage]
    A --> D[Issue 3: Docker CVEs]

    B --> E[Update Test Wait Strategy]
    E --> F[Run 10 Consecutive Firefox Tests]
    F --> G[Validate Success Rate]

    C --> H[Delete Stale Coverage Files]
    H --> I[Run Coverage Skill]
    I --> J{Coverage ≥85%?}
    J -->|Yes| K[Verify Stale Data]
    J -->|No| L[Add Missing Tests]
    L --> I
    K --> M[Document Verification]

    D --> N[Create Security Advisory]
    N --> O[Risk Acceptance Review]
    O --> P[Monitoring Setup]

    G --> Q[Phase Complete]
    M --> Q
    P --> Q

---

Phase 3: IMPLEMENTATION PLAN

Task Breakdown

🔴 PHASE 1: E2E Test Stability Fixes (CRITICAL)

Priority: P0 - Must be fixed before merge Estimated Effort: 3-5 hours Assignee: Developer Agent Dependencies: None

Task 1.1: Add data-testid to DNSProviderForm Component

File: frontend/src/components/DNSProviderForm.tsx Line: ~209

BEFORE:

<Label>
  {t('dnsProviders.credentials')}
</Label>

AFTER:

<Label data-testid="credentials-section">
  {t('dnsProviders.credentials')}
</Label>

Rationale:

• Provides stable test anchor independent of translations
• Best practice for E2E testing (per Playwright docs)
• Immune to CSS class or text content changes

Verification:

# Verify component renders with data-testid
npm run build
# Check no TypeScript errors
npm run lint

---

Task 1.2: Update Webhook Provider Test

File: tests/dns-provider-types.spec.ts Test Name: "should show URL field when Webhook type is selected"

BEFORE (lines ~202-215):

await test.step('Wait for form to load', async () => {
  await page.waitForTimeout(500);
});

await test.step('Verify dynamic fields appear', async () => {
  const urlLabel = page.locator('label').filter({ hasText: /create.*url|url/i });
  await expect(urlLabel).toBeVisible();
});

AFTER:

await test.step('Wait for credentials section to appear', async () => {
  await page.locator('[data-testid="credentials-section"]').waitFor({
    state: 'visible',
    timeout: 10000  // Increased for Firefox compatibility
  });
});

await test.step('Verify Webhook URL field appears', async () => {
  // Use accessibility-focused locator
  await expect(page.getByLabel(/create url/i)).toBeVisible({ timeout: 5000 });
});

---

Task 1.3: Update RFC2136 Provider Test

File: tests/dns-provider-types.spec.ts Test Name: "should show DNS Server field when RFC2136 type is selected"

BEFORE (lines ~223-241):

await test.step('Wait for form to load', async () => {
  await page.waitForTimeout(500);
});

await test.step('Verify RFC2136-specific fields appear', async () => {
  const serverLabel = page.locator('label').filter({ hasText: /server|nameserver|host/i });
  await expect(serverLabel).toBeVisible();
});

AFTER:

await test.step('Wait for credentials section to appear', async () => {
  await page.locator('[data-testid="credentials-section"]').waitFor({
    state: 'visible',
    timeout: 10000  // Increased for Firefox compatibility
  });
});

await test.step('Verify RFC2136 server field appears', async () => {
  await expect(page.getByLabel(/dns server/i)).toBeVisible({ timeout: 5000 });
});

---

Task 1.4: Validation - 10 Consecutive Test Runs

Prerequisite: Rebuild E2E environment

# CRITICAL: Rebuild E2E container before validation
.github/skills/scripts/skill-runner.sh docker-rebuild-e2e

Validation Commands:

# Webhook provider test (10 runs)
for i in {1..10}; do
  echo "Run $i/10: Webhook test"
  npx playwright test tests/dns-provider-types.spec.ts \
    --grep "should show URL field when Webhook type is selected" \
    --project=firefox || break
done

# RFC2136 provider test (10 runs)
for i in {1..10}; do
  echo "Run $i/10: RFC2136 test"
  npx playwright test tests/dns-provider-types.spec.ts \
    --grep "should show DNS Server field when RFC2136 type is selected" \
    --project=firefox || break
done

Success Criteria: All 20 test runs pass (10 Webhook + 10 RFC2136)

Note: If tests still fail in Firefox, escalate with trace data:

npx playwright test --project=firefox --trace on

---

🔴 PHASE 2: Backend Coverage Verification (CRITICAL)

Priority: P0 - Must be verified before merge Estimated Effort: 1-2 hours Assignee: Developer Agent Dependencies: None

Task 2.1: Clean Stale Coverage Files

cd backend
rm -f coverage.out coverage.txt coverage.html

---

Task 2.2: Run Fresh Coverage Analysis

.github/skills/scripts/skill-runner.sh test-backend-coverage

Expected Output:

Filtering excluded packages from coverage report...
total:  (statements)    XX.X%
Computed coverage: XX.X% (minimum required 85%)
Coverage requirement met

---

Task 2.3: Document Coverage Verification

Scenario A: Coverage ≥85% (Likely - create verification report)

File: docs/reports/backend_coverage_verification.md

# Backend Coverage Verification Report

**Date**: 2026-02-01
**Issue**: QA reported 24.7% coverage (stale data suspected)

## Results
**Command**: `.github/skills/scripts/skill-runner.sh test-backend-coverage`
**Total Coverage**: XX.X%
**Status**: ✅ PASS (≥85%)

## Conclusion
Original 24.7% was from stale coverage file.
Fresh analysis confirms coverage meets threshold.

Scenario B: Coverage <85% (Unlikely - add tests)

1. Generate HTML: go tool cover -html=backend/coverage.txt -o coverage.html
2. Identify gaps from HTML report
3. Add targeted unit tests
4. Re-run coverage
5. Repeat until ≥85%

---

Task 2.4: Codecov Patch Coverage Verification

1. Push changes to PR branch
2. Wait for Codecov report
3. Check patch coverage percentage
4. If <100%, add tests for uncovered lines
5. Repeat until 100%

---

🟠 PHASE 3: Docker Security Documentation (HIGH)

Priority: P1 - Must be documented before merge Estimated Effort: 1-2 hours Assignee: Developer Agent Dependencies: Security team availability, fresh Grype scan

Task 3.1: Run Fresh Grype Scan

Command:

.github/skills/scripts/skill-runner.sh security-scan-docker-image

Purpose:

• Verify CVE list is current as of February 2026
• Identify if any HIGH CVEs have patches available
• Generate fresh vulnerability data for security advisory

Expected Output:

• Updated vulnerability count and CVSS scores
• Confirmation of 7 HIGH CVEs (or updated count)
• Latest fix availability status

Validation:

# Check scan results
cat grype-results.json | jq '.matches[] | select(.vulnerability.severity == "High") | .vulnerability.id'

---

Task 3.2: Create Security Advisory

File: docs/security/advisory_2026-02-01_base_image_cves.md

Required Sections:

1. Executive Summary: CVE count, severity distribution, patch status
2. CVE Details Table: ID, Package, CVSS, Fix Status, Description (from fresh Grype scan)
3. Risk Assessment: Exploitability, Container Context, Application Impact
4. Risk Acceptance Justification: Why accepting these CVEs is acceptable
5. Mitigation Factors: Security controls reducing risk (read-only FS, non-root, etc.)
6. Monitoring Plan: Weekly scans, security mailing list subscription
7. Expiration Date: Risk acceptance expires in 90 days (May 2, 2026) - requires re-evaluation

Template:

# Security Advisory: Docker Base Image Vulnerabilities

**Date**: 2026-02-01
**Expiration**: 2026-05-02 (90 days)
**Status**: Risk Accepted
**Reviewed By**: [Security Team Lead]
**Approved By**: [Tech Lead]

## Executive Summary
- **Total Vulnerabilities**: [from fresh scan]
- **HIGH Severity**: [count from fresh scan]
- **Patches Available**: [count from fresh scan]
- **Risk Level**: Acceptable with monitoring

## CVE Details
[Table generated from fresh Grype scan results]

## Risk Assessment
...

## Expiration and Re-evaluation
This risk acceptance expires on **May 2, 2026**. A fresh security review must be conducted before this date to:
- Verify patch availability
- Re-assess risk level
- Renew or revoke acceptance

---

Task 3.3: Security Team Review

Deliverables:

• Security advisory (Task 3.1)
• Risk acceptance form
• Monitoring plan verification

---

Phase 4: VALIDATION

Validation Checklist

Issue 1: Firefox E2E Tests

• Webhook test passes 10 consecutive runs
• RFC2136 test passes 10 consecutive runs
• No timeout errors
• Test duration <10 seconds per run

Issue 2: Backend Coverage

• Fresh coverage ≥85% verified
• Coverage.txt generated
• No test failures
• Codecov reports 100% patch coverage

Issue 3: Docker Security

• Security advisory created
• Risk acceptance form signed
• Monitoring plan configured
• Security team approval documented

Definition of Done

Critical Requirements (Must Pass):

• E2E Firefox tests: 10 consecutive passes (Webhook)
• E2E Firefox tests: 10 consecutive passes (RFC2136)
• Backend coverage: ≥85% verified
• Codecov patch: 100% coverage
• Docker security: Advisory documented and approved

Quality Requirements:

• Type safety: No TypeScript errors
• Linting: Pre-commit hooks pass
• CodeQL: No new security issues
• CI pipeline: All workflows green

Documentation Requirements:

• Coverage verification report created
• Security advisory created
• Risk acceptance signed
• CHANGELOG.md updated

---

Phase 5: REFLECT

Lessons Learned

Firefox Test Stability:

• Root Cause: 5-second timeout too short for Firefox, not incorrect selector
• Element Type: "Credentials" is a Label element (line 209), not a heading
• Current Selector: page.getByText(/^credentials$/i) was already correct
• Solution: Add data-testid for stability + increase timeout to 10 seconds
• Best Practice: Use test-specific attributes (data-testid) for critical test anchors
• Translation Safety: data-testid immune to i18n key changes

Backend Coverage:

• Stale coverage files misreport status
• Always clean coverage files before fresh analysis
• Future: Add coverage file age check to CI

Docker Security:

• Base image CVEs may not have patches for extended periods
• Document risk acceptance with monitoring plan and expiration date
• Future: Evaluate Alpine Linux as alternative

---

Technical Debt Identified

TD-1: Test Helper Function (LOW - P3)

• Extract credentials section wait to tests/helpers.ts for reuse
• Current: Inline locator in each test
• Effort: 30 minutes

TD-2: Coverage File Lifecycle (MEDIUM - P2)

• Automate cleanup of old coverage files in CI
• Current: Manual deletion required
• Effort: 1 hour

---

Phase 6: HANDOFF

Executive Summary

Decision: Implement 3-phase remediation for QA audit blocking issues Rationale: Firefox instability and coverage verification are merge blockers; CVEs require documentation Impact: Unblocks PR merge, improves E2E reliability, establishes security documentation process Review: Post-merge monitoring for Firefox stability (1 week), coverage verification enforcement (immediate)

---

Pull Request Content

Title: fix: Resolve QA audit blocking issues - E2E Firefox tests, coverage, CVE docs

Body:

## Summary
Resolves 3 critical QA audit issues:
1. E2E Firefox test instability (Webhook & RFC2136) - timeout issue
2. Backend coverage verification (stale data)
3. Docker CVE documentation (7 HIGH)

## Changes
- **frontend/src/components/DNSProviderForm.tsx**: Added data-testid to credentials section
- **tests/dns-provider-types.spec.ts**: Use data-testid selector with 10s timeout for Firefox
- **docs/reports/backend_coverage_verification.md**: Coverage report
- **docs/security/advisory_2026-02-01_base_image_cves.md**: Security advisory with 90-day expiration

## Validation
- ✅ 20 consecutive Firefox test passes (10 Webhook + 10 RFC2136)
- ✅ Backend coverage XX.X% (≥85%)
- ✅ Codecov patch 100%
- ✅ Security advisory approved with 90-day expiration

## References
- QA Report: docs/reports/qa_report_dns_provider_e2e_fixes.md
- Remediation Plan: docs/plans/current_spec.md

• Remediation Plan: docs/plans/current_spec.md

---

### Artifacts

**Documentation**:
- `docs/plans/current_spec.md` - This remediation plan
- `docs/plans/qa_remediation_full_plan.md` - Detailed implementation tasks
- `docs/reports/backend_coverage_verification.md` - Coverage verification
- `docs/security/advisory_2026-02-01_base_image_cves.md` - Security advisory

**Test Results**:
- `test-results/validation_report_firefox_10x.txt` - 20 consecutive runs
- `backend/coverage.txt` - Fresh coverage report

---

### Next Steps

**Immediate** (Developer Agent):
1. Implement Phase 1 (E2E fixes)
2. Execute Phase 2 (coverage verification)
3. Create Phase 3 documents (security advisory)
4. Run full validation checklist

**Review** (Supervisor Agent):
1. Validate E2E stability (10 consecutive runs)
2. Review coverage verification
3. Validate security advisory completeness

**Post-Merge**:
1. Monitor Firefox test stability (1 week)
2. Track Debian security advisories
3. Address technical debt (P2/P3)

---

## Risk Assessment

### Risk 1: Firefox Test Still Flaky
**Likelihood**: Low (15%)
**Mitigation**: Semantic locators + 5s timeout + manual Firefox testing

### Risk 2: Coverage Actually <85%
**Likelihood**: Very Low (5%)
**Mitigation**: HTML report for gap identification + parallel test development

### Risk 3: Security Review Delays
**Likelihood**: Low (10%)
**Mitigation**: Template provided, async approval, escalation path available

---

## References

**Primary Documents**:
- QA Report: `docs/reports/qa_report_dns_provider_e2e_fixes.md`
- Testing Protocols: `.github/instructions/testing.instructions.md`
- Test File: `tests/dns-provider-types.spec.ts`
- Form Component: `frontend/src/components/DNSProviderForm.tsx` (line 209 - "Credentials" Label element)

**External Resources**:
- Playwright Best Practices: https://playwright.dev/docs/best-practices
- Codecov Docs: https://docs.codecov.com/
- Debian Security Tracker: https://security-tracker.debian.org/

---

**Plan Status**: ✅ READY FOR SUPERVISOR REVIEW
**Confidence Score**: 90% (High Confidence)
**Created**: 2026-02-01
**Author**: Principal Architect Agent (Planning Mode)
**Estimated Total Effort**: 6-10 hours
**Risk Level**: Low-Medium

---

## DEPRECATED SECTIONS (Historical Reference Only)

The following sections are from an earlier iteration of this plan and have been superseded by the corrected Phase 1-3 implementation above. They are kept for historical reference only.

### ~~Phase 1: Remove Dead Code (DEPRECATED)~~

**NOTE**: This phase was removed after Supervisor review identified the root cause was timeout, not dead code.

### ~~Phase 2: E2E Test Waiting Strategies (DEPRECATED)~~

**NOTE**: This phase incorrectly assumed "Credentials" was a heading element. Corrected implementation in Phase 1 uses data-testid.

### Optional Enhancements (Supervisor Recommended)

**3.0.1: Manual UI Smoke Test Checklist**

Before committing changes, perform manual verification:

- [ ] Open DNS provider form in UI
- [ ] Select each provider type (Cloudflare, Manual, RFC2136, Webhook)
- [ ] Verify credential fields render correctly within 2 seconds
- [ ] Verify no console errors in browser DevTools
- [ ] Test form submission with valid credentials
- [ ] Verify form validation messages appear for invalid input

**3.0.2: Extended Test Validation (If CI Historically Flaky)**

If the project has a history of E2E flakiness, consider:

```bash
# Run 20 times instead of 10 for higher confidence (already covered in Phase 1, Task 1.4)

3.0.3: Coverage Validation

Verify test coverage after changes:

# Run E2E tests with coverage
.github/skills/scripts/skill-runner.sh test-e2e-playwright-coverage

# Check coverage report
open coverage/e2e/index.html

# Verify non-zero coverage for modified files
grep -A 5 "DNSProviderForm" coverage/e2e/lcov.info

3.0.4: Document Waiting Strategy

Add comments in test file explaining the waiting strategy:

// IMPLEMENTATION NOTE: We wait for the credentials section using data-testid
// as a reliable, translation-independent indicator that React Query has loaded
// DNS provider type data. The 10-second timeout accommodates slower Firefox
// rendering. See docs/plans/current_spec.md for detailed analysis.

---

Acceptance Criteria (EARS Notation)

REQ-1: WHEN data-testid is added to DNSProviderForm, THE SYSTEM SHALL compile without TypeScript errors.

REQ-2: WHEN a user selects a DNS provider type in the UI, THE SYSTEM SHALL render the correct credential fields within 2 seconds.

REQ-3: WHEN the Webhook E2E test executes in Firefox, THE SYSTEM SHALL pass 10 consecutive runs.

REQ-4: WHEN the RFC2136 E2E test executes in Firefox, THE SYSTEM SHALL pass 10 consecutive runs.

REQ-5: WHEN the full E2E test suite runs in CI, THE SYSTEM SHALL pass without failures.

REQ-6: WHEN a fresh Grype scan is executed, THE SYSTEM SHALL generate current CVE data for security advisory.

REQ-7: WHEN security advisory is created, THE SYSTEM SHALL include 90-day expiration date for risk acceptance.

---

Next Steps

1. Supervisor Review: Present this plan to Supervisor agent for approval
2. Implementation Assignment: Assign implementation to Developer agent with this spec
3. CI Monitoring: Monitor CI runs for 24 hours post-merge to catch edge cases
4. Backport Consideration: Evaluate if fix should be backported to previous release branch

---

References

Primary Files Analyzed

• tests/dns-provider-types.spec.ts - Failing E2E tests (lines 202, 223)
• frontend/src/components/DNSProviderForm.tsx - Form component (line 209 - Label element)
• backend/pkg/dnsprovider/custom/rfc2136_provider.go - RFC2136 field definitions
• backend/pkg/dnsprovider/custom/webhook_provider.go - Webhook field definitions
• backend/internal/api/handlers/dns_provider_handler.go - API handlers

External Resources

• CI Job: https://github.com/Wikid82/Charon/actions/runs/21558579945/job/62119064955?pr=583
• Playwright Documentation: Best Practices for Waiting - https://playwright.dev/docs/best-practices#use-web-first-assertions
• React Query Docs: Stale Time Configuration - https://tanstack.com/query/latest/docs/framework/react/guides/important-defaults

---

Plan Completed: 2026-02-01 Ready for Supervisor Review: ✅ Estimated Implementation Time: 4-6 hours Risk Level: Low