akanealw/Charon
1
0
Fork 0
Code Issues Pull Requests Actions 5 Packages Projects Releases Wiki Activity

feat: add ManualDNSChallenge component and related hooks for manual DNS challenge management

Browse Source 
- Implemented `useManualChallenge`, `useChallengePoll`, and `useManualChallengeMutations` hooks for managing manual DNS challenges.
- Created tests for the `useManualChallenge` hooks to ensure correct fetching and mutation behavior.
- Added `ManualDNSChallenge` component for displaying challenge details and actions.
- Developed end-to-end tests for the Manual DNS Provider feature, covering provider selection, challenge UI, and accessibility compliance.
- Included error handling tests for verification failures and network errors.
This commit is contained in:
GitHub Actions
2026-01-12 04:01:40 +00:00
parent a199dfd079
commit d7939bed70
132 changed files with 8680 additions and 878 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
.github/agents/Managment.agent.md vendored
View File

@@ -72,22 +72,30 @@ You are "lazy" in the smartest way possible. You never do what a subordinate can
The task is not complete until ALL of the following pass with zero issues:
1. **Coverage Tests (MANDATORY - Verify Explicitly)**:
1. **Playwright E2E Tests (MANDATORY - Run First)**:
- **Run**: `npx playwright test --project=chromium` from project root
- **Why First**: If the app is broken at E2E level, unit tests may need updates. Catch integration issues early.
- **Scope**: Run tests relevant to modified features (e.g., `tests/manual-dns-provider.spec.ts`)
- **On Failure**: Trace root cause through frontend → backend flow before proceeding
- **Base URL**: Uses `PLAYWRIGHT_BASE_URL` or default from `playwright.config.js`
- All E2E tests must pass before proceeding to unit tests
2. **Coverage Tests (MANDATORY - Verify Explicitly)**:
- **Backend**: Ensure `Backend_Dev` ran VS Code task "Test: Backend with Coverage" or `scripts/go-test-coverage.sh`
- **Frontend**: Ensure `Frontend_Dev` ran VS Code task "Test: Frontend with Coverage" or `scripts/frontend-test-coverage.sh`
- **Why**: These are in manual stage of pre-commit for performance. Subagents MUST run them via VS Code tasks or scripts.
- Minimum coverage: 85% for both backend and frontend.
- All tests must pass with zero failures.
2. **Type Safety (Frontend)**:
3. **Type Safety (Frontend)**:
- Ensure `Frontend_Dev` ran VS Code task "Lint: TypeScript Check" or `npm run type-check`
- **Why**: This check is in manual stage of pre-commit for performance. Subagents MUST run it explicitly.
3. **Pre-commit Hooks**: Ensure `QA_Security` ran `pre-commit run --all-files` (fast hooks only; coverage was verified in step 1)
4. **Pre-commit Hooks**: Ensure `QA_Security` ran `pre-commit run --all-files` (fast hooks only; coverage was verified in step 2)
4. **Security Scans**: Ensure `QA_Security` ran CodeQL and Trivy with zero Critical or High severity issues
5. **Security Scans**: Ensure `QA_Security` ran CodeQL and Trivy with zero Critical or High severity issues
5. **Linting**: All language-specific linters must pass
6. **Linting**: All language-specific linters must pass
**Your Role**: You delegate implementation to subagents, but YOU are responsible for verifying they completed the Definition of Done. Do not accept "DONE" from a subagent until you have confirmed they ran coverage tests, type checks, and security scans explicitly.

21
.github/agents/Planning.agent.md vendored
View File

@@ -67,9 +67,12 @@ Your goal is to design the **User Experience** first, then engineer the **Backen
}
```
### 🕵️ Phase 1: QA & Security
### 🕵️ Phase 1: Playwright E2E Tests (Run First)
1. Build tests for coverage of perposed code additions and chages based on how the code SHOULD work
1. Run `npx playwright test --project=chromium` to verify app functions correctly
2. If tests fail, trace root cause through frontend → backend flow
3. Write/update Playwright tests for new features in `tests/*.spec.ts`
4. Build unit tests for coverage of proposed code additions and changes based on how the code SHOULD work
### 🏗️ Phase 2: Backend Implementation (Go)
@@ -89,15 +92,19 @@ Your goal is to design the **User Experience** first, then engineer the **Backen
### 🕵️ Phase 3: QA & Security
1. Edge Cases: {List specific scenarios to test}
2. **Coverage Tests (MANDATORY)**:
1. **Playwright E2E Tests (MANDATORY - Run First)**:
- Run `npx playwright test --project=chromium` from project root
- All E2E tests must pass BEFORE running unit tests
- If E2E fails, trace root cause and fix before proceeding
2. Edge Cases: {List specific scenarios to test}
3. **Coverage Tests (MANDATORY - After E2E passes)**:
- Backend: Run VS Code task "Test: Backend with Coverage" or execute `scripts/go-test-coverage.sh`
- Frontend: Run VS Code task "Test: Frontend with Coverage" or execute `scripts/frontend-test-coverage.sh`
- Minimum coverage: 85% for both backend and frontend
- **Critical**: These are in manual stage of pre-commit for performance. Agents MUST run them via VS Code tasks or scripts before marking tasks complete.
3. Security: Run CodeQL and Trivy scans. Triage and fix any new errors or warnings.
4. **Type Safety (Frontend)**: Run VS Code task "Lint: TypeScript Check" or execute `cd frontend && npm run type-check`
5. Linting: Run `pre-commit` hooks on all files and triage anything not auto-fixed.
4. Security: Run CodeQL and Trivy scans. Triage and fix any new errors or warnings.
5. **Type Safety (Frontend)**: Run VS Code task "Lint: TypeScript Check" or execute `cd frontend && npm run type-check`
6. Linting: Run `pre-commit` hooks on all files and triage anything not auto-fixed.
### 📚 Phase 4: Documentation

18
.github/agents/QA_Security.agent.md vendored
View File

@@ -70,13 +70,21 @@ When Trivy or CodeQLreports CVEs in container dependencies (especially Caddy tra
The task is not complete until ALL of the following pass with zero issues:
1. **Security Scans**:
1. **Playwright E2E Tests (MANDATORY - Run First)**:
- **Run**: `npx playwright test --project=chromium` from project root
- **Why First**: If the app is broken at E2E level, unit tests may need updates. Catch integration issues early.
- **Scope**: Run tests relevant to modified features (e.g., `tests/manual-dns-provider.spec.ts`)
- **On Failure**: Trace root cause through frontend → backend flow, report to Management or Dev subagent
- **Base URL**: Uses `PLAYWRIGHT_BASE_URL` or default `http://100.98.12.109:8080`
- All E2E tests must pass before proceeding
2. **Security Scans**:
- CodeQL: Run VS Code task "Security: CodeQL All (CI-Aligned)" or individual Go/JS tasks
- Trivy: Run VS Code task "Security: Trivy Scan"
- Go Vulnerabilities: Run VS Code task "Security: Go Vulnerability Check"
- Zero Critical/High issues allowed
2. **Coverage Tests (MANDATORY - Run Explicitly)**:
3. **Coverage Tests (MANDATORY - Run Explicitly)**:
- **MANDATORY**: Patch coverage must cover 100% of new/modified code. This prevents CodeCov Report failing CI.
- **Backend**: Run VS Code task "Test: Backend with Coverage" or execute `scripts/go-test-coverage.sh`
- **Frontend**: Run VS Code task "Test: Frontend with Coverage" or execute `scripts/frontend-test-coverage.sh`
@@ -84,14 +92,14 @@ The task is not complete until ALL of the following pass with zero issues:
- Minimum coverage: 85% for both backend and frontend.
- All tests must pass with zero failures.
3. **Type Safety (Frontend)**:
4. **Type Safety (Frontend)**:
- Run VS Code task "Lint: TypeScript Check" or execute `cd frontend && npm run type-check`
- **Why**: This check is in manual stage of pre-commit for performance. You MUST run it explicitly.
- Fix all type errors immediately.
4. **Pre-commit Hooks**: Run `pre-commit run --all-files` (this runs fast hooks only; coverage was verified in step 1)
5. **Pre-commit Hooks**: Run `pre-commit run --all-files` (this runs fast hooks only; coverage was verified in step 3)
5. **Linting (MANDATORY - Run All Explicitly)**:
6. **Linting (MANDATORY - Run All Explicitly)**:
- **Backend GolangCI-Lint**: Run VS Code task "Lint: GolangCI-Lint (Docker)" - This is the FULL linter suite including gocritic, bodyclose, etc.
- **Why**: "Lint: Go Vet" only runs `go vet`, NOT the full golangci-lint suite. CI runs golangci-lint, so you MUST run this task to match CI behavior.
- **Command**: `cd backend && docker run --rm -v $(pwd):/app:ro -w /app golangci/golangci-lint:latest golangci-lint run -v`

29
.github/instructions/copilot-instructions.md vendored
View File

@@ -114,7 +114,15 @@ Before proposing ANY code change or fix, you must build a mental map of the feat
Before marking an implementation task as complete, perform the following in order:
1. **Security Scans** (MANDATORY - Zero Tolerance):
1. **Playwright E2E Tests** (MANDATORY - Run First):
- **Run**: `npx playwright test --project=chromium` from project root
- **Why First**: If the app is broken at E2E level, unit tests may need updates. Catch integration issues early.
- **Scope**: Run tests relevant to modified features (e.g., `tests/manual-dns-provider.spec.ts`)
- **On Failure**: Trace root cause through frontend → backend flow before proceeding
- **Base URL**: Uses `PLAYWRIGHT_BASE_URL` or default from `playwright.config.js`
- All E2E tests must pass before proceeding to unit tests
2. **Security Scans** (MANDATORY - Zero Tolerance):
- **CodeQL Go Scan**: Run VS Code task "Security: CodeQL Go Scan (CI-Aligned)" OR `pre-commit run codeql-go-scan --all-files`
- Must use `security-and-quality` suite (CI-aligned)
- **Zero high/critical (error-level) findings allowed**
@@ -136,12 +144,12 @@ Before marking an implementation task as complete, perform the following in orde
- Database creation: `--threads=0 --overwrite`
- Analysis: `--sarif-add-baseline-file-info`
2. **Pre-Commit Triage**: Run `pre-commit run --all-files`.
3. **Pre-Commit Triage**: Run `pre-commit run --all-files`.
- If errors occur, **fix them immediately**.
- If logic errors occur, analyze and propose a fix.
- Do not output code that violates pre-commit standards.
3. **Staticcheck BLOCKING Validation**: Pre-commit hooks automatically run fast linters including staticcheck.
4. **Staticcheck BLOCKING Validation**: Pre-commit hooks automatically run fast linters including staticcheck.
- **CRITICAL:** Staticcheck errors are BLOCKING - you MUST fix them before commit succeeds.
- Manual verification: Run VS Code task "Lint: Staticcheck (Fast)" or `make lint-fast`
- To check only staticcheck: `make lint-staticcheck-only`
@@ -149,7 +157,7 @@ Before marking an implementation task as complete, perform the following in orde
- If pre-commit fails: Fix the reported issues, then retry commit
- **Do NOT** use `--no-verify` to bypass this check unless emergency hotfix
4. **Coverage Testing** (MANDATORY - Non-negotiable):
5. **Coverage Testing** (MANDATORY - Non-negotiable):
- **MANDATORY**: Patch coverage must cover 100% of modified lines (Codecov Patch view must be green). If patch coverage fails, add targeted tests for the missing patch line ranges.
- **Backend Changes**: Run the VS Code task "Test: Backend with Coverage" or execute `scripts/go-test-coverage.sh`.
- Minimum coverage: 85% (set via `CHARON_MIN_COVERAGE` or `CPM_MIN_COVERAGE`).
@@ -162,22 +170,21 @@ Before marking an implementation task as complete, perform the following in orde
- **Critical**: Coverage tests are NOT run by default pre-commit hooks (they are in manual stage for performance). You MUST run them explicitly via VS Code tasks or scripts before completing any task.
- **Why**: CI enforces coverage in GitHub Actions. Local verification prevents CI failures and maintains code quality.
4. **Type Safety** (Frontend only):
6. **Type Safety** (Frontend only):
- Run the VS Code task "Lint: TypeScript Check" or execute `cd frontend && npm run type-check`.
- Fix all type errors immediately. This is non-negotiable.
- This check is also in manual stage for performance but MUST be run before completion.
5. **Verify Build**: Ensure the backend compiles and the frontend builds without errors.
7. **Verify Build**: Ensure the backend compiles and the frontend builds without errors.
- Backend: `cd backend && go build ./...`
- Frontend: `cd frontend && npm run build`
6. **Fixed and New Code Testing**:
- Ensure all existing and new unit tests pass with zero failures using Playwright MCP.
- When fasilures and Errors are found, deep-dive into root causes. Using the correct `subAgent`, update the working plan, review the implementation, and fix the issues.
8. **Fixed and New Code Testing**:
- Ensure all existing and new unit tests pass with zero failures.
- When failures and errors are found, deep-dive into root causes. Using the correct `subAgent`, update the working plan, review the implementation, and fix the issues.
- No issue is out of scope for investigation and resolution. All issues must be addressed before task completion.
6. **Clean Up**: Ensure no debug print statements or commented-out blocks remain.
9. **Clean Up**: Ensure no debug print statements or commented-out blocks remain.
- Remove `console.log`, `fmt.Println`, and similar debugging statements.
- Delete commented-out code blocks.
- Remove unused imports.

10
.github/instructions/testing.instructions.md vendored
View File

@@ -4,6 +4,16 @@ description: 'Strict protocols for test execution, debugging, and coverage valid
---
# Testing Protocols
## 0. E2E Verification First (Playwright)
**MANDATORY**: Before running unit tests, verify the application functions correctly end-to-end.
* **Run Playwright E2E Tests**: Execute `npx playwright test --project=chromium` from the project root.
* **Why First**: If the application is broken at the E2E level, unit tests may need updates. Playwright catches integration issues early.
* **Base URL**: Tests use `PLAYWRIGHT_BASE_URL` env var or default from `playwright.config.js` (Tailscale IP: `http://100.98.12.109:8080`).
* **On Failure**: Analyze failures, trace root cause through frontend → backend flow, then fix before proceeding to unit tests.
* **Scope**: Run relevant test files for the feature being modified (e.g., `tests/manual-dns-provider.spec.ts`).
## 1. Execution Environment
* **No Truncation:** Never use pipe commands (e.g., `head`, `tail`) or flags that limit stdout/stderr. If a test hangs, it likely requires an interactive input or is caught in a loop; analyze the full output to identify the block.
* **Task-Based Execution:** Do not manually construct test strings. Use existing project tasks (e.g., `npm test`, `go test ./...`). If a specific sub-module requires frequent testing, generate a new task definition in the project's configuration file (e.g., `.vscode/tasks.json`) before proceeding.