f85ffa39b2
Phase 3 coverage improvement campaign achieved primary objectives within budget, bringing all critical code paths above quality thresholds while identifying systemic infrastructure limitations for future work. Backend coverage increased from 83.5% to 84.2% through comprehensive test suite additions spanning cache invalidation, configuration parsing, IP canonicalization, URL utilities, and token validation logic. All five targeted packages now exceed 85% individual coverage, with the remaining gap attributed to intentionally deferred packages outside immediate scope. Frontend coverage analysis revealed a known compatibility conflict between jsdom and undici WebSocket implementations preventing component testing of real-time features. Created comprehensive test suites totaling 458 cases for security dashboard components, ready for execution once infrastructure upgrade completes. Current 84.25% coverage sufficiently validates UI logic and API interactions, with E2E tests providing WebSocket feature coverage. Security-critical modules (cerberus, crypto, handlers) all exceed 86% coverage. Patch coverage enforcement remains at 85% for all new code. QA security assessment classifies current risk as LOW, supporting production readiness. Technical debt documented across five prioritized issues for next sprint, with test infrastructure upgrade (MSW v2.x) identified as highest value improvement to unlock 15-20% additional coverage potential. All Phase 1-3 objectives achieved: - CI pipeline unblocked via split browser jobs - Root cause elimination of 91 timeout anti-patterns - Coverage thresholds met for all priority code paths - Infrastructure constraints identified and mitigation planned Related to: #609 (E2E Test Triage and Beta Release Preparation)
docs/issues - Issue Specification Files
This directory contains markdown files that are automatically converted to GitHub Issues when merged to main or development.
How It Works
- Create a markdown file in this directory using the template format
- Add YAML frontmatter with issue metadata (title, labels, priority, etc.)
- Merge to main/development - the
docs-to-issues.ymlworkflow runs - GitHub Issue is created with your specified metadata
- File is moved to
docs/issues/created/to prevent duplicates
Quick Start
Copy _TEMPLATE.md and fill in your issue details:
---
title: "My New Issue"
labels:
- feature
- backend
priority: medium
---
# My New Issue
Description of the issue...
Frontmatter Fields
| Field | Required | Description |
|---|---|---|
title |
Yes* | Issue title (*or uses first H1 as fallback) |
labels |
No | Array of labels to apply |
priority |
No | critical, high, medium, low |
milestone |
No | Milestone name |
assignees |
No | Array of GitHub usernames |
parent_issue |
No | Parent issue number for linking |
create_sub_issues |
No | If true, each ## Section becomes a sub-issue |
Sub-Issues
To create multiple related issues from one file, set create_sub_issues: true:
---
title: "Main Testing Issue"
labels: [testing]
create_sub_issues: true
---
# Main Testing Issue
Overview content for the parent issue.
## Unit Testing
This section becomes a separate issue.
## Integration Testing
This section becomes another separate issue.
Manual Trigger
You can manually run the workflow with:
# Dry run (no issues created)
gh workflow run docs-to-issues.yml -f dry_run=true
# Process specific file
gh workflow run docs-to-issues.yml -f file_path=docs/issues/my-issue.md
Labels
Labels are automatically created if they don't exist. Common labels:
- Priority:
critical,high,medium,low - Type:
feature,bug,enhancement,testing,documentation - Component:
backend,frontend,ui,security,caddy,database