diff --git a/.github/aw/schemas/agentic-workflow.json b/.github/aw/schemas/agentic-workflow.json index 126375ba30..d269a6bc0a 100644 --- a/.github/aw/schemas/agentic-workflow.json +++ b/.github/aw/schemas/agentic-workflow.json @@ -3680,6 +3680,54 @@ } ] }, + "copy-project": { + "oneOf": [ + { + "type": "object", + "description": "Configuration for copying GitHub Projects v2 boards. Creates a new project with the same structure, fields, and views as the source project. By default, draft issues are NOT copied unless explicitly requested with includeDraftIssues=true in the tool call. Requires a Personal Access Token (PAT) or GitHub App token with Projects permissions; the GITHUB_TOKEN cannot be used. Safe output items use type=copy_project and include: sourceProject (URL), owner (org/user login), title (new project name), and optional includeDraftIssues (boolean). The source-project and target-owner can be configured in the workflow frontmatter to provide defaults that the agent can use or override.", + "properties": { + "max": { + "type": "integer", + "description": "Maximum number of copy operations to perform (default: 1).", + "minimum": 1, + "maximum": 100 + }, + "github-token": { + "$ref": "#/$defs/github_token", + "description": "GitHub token to use for this specific output type. Must have Projects write permission. Overrides global github-token if specified." + }, + "source-project": { + "type": "string", + "pattern": "^https://github\\.com/(orgs|users)/[^/]+/projects/\\d+$", + "description": "Optional default source project URL to copy from (e.g., 'https://github.com/orgs/myorg/projects/42'). If specified, the agent can omit the sourceProject field in the tool call and this default will be used. The agent can still override by providing a sourceProject in the tool call." + }, + "target-owner": { + "type": "string", + "description": "Optional default target owner (organization or user login name) where the new project will be created (e.g., 'myorg' or 'username'). If specified, the agent can omit the owner field in the tool call and this default will be used. The agent can still override by providing an owner in the tool call." + } + }, + "additionalProperties": false, + "examples": [ + { + "max": 1 + }, + { + "github-token": "${{ secrets.PROJECT_GITHUB_TOKEN }}", + "max": 1 + }, + { + "source-project": "https://github.com/orgs/myorg/projects/42", + "target-owner": "myorg", + "max": 1 + } + ] + }, + { + "type": "null", + "description": "Enable project copying with default configuration (max=1)" + } + ] + }, "create-project-status-update": { "oneOf": [ { diff --git a/.github/workflows/daily-firewall-report.lock.yml b/.github/workflows/daily-firewall-report.lock.yml index 337f54363d..048dfb3ad1 100644 --- a/.github/workflows/daily-firewall-report.lock.yml +++ b/.github/workflows/daily-firewall-report.lock.yml @@ -614,7 +614,7 @@ jobs: 1. **Firewall Request Data**: - Count of allowed requests per day - - Count of denied/blocked requests per day + - Count of blocked requests per day - Total requests per day 2. **Top Blocked Domains Data**: @@ -624,7 +624,7 @@ jobs: **Phase 2: Data Preparation** 1. Create CSV files in `/tmp/gh-aw/python/data/` with the collected data: - - `firewall_requests.csv` - Daily allowed/denied request counts + - `firewall_requests.csv` - Daily allowed/blocked request counts - `blocked_domains.csv` - Top blocked domains with frequencies 2. Each CSV should have a date column and metric columns with appropriate headers @@ -636,7 +636,7 @@ jobs: **Chart 1: Firewall Request Trends** - Stacked area chart or multi-line chart showing: - Allowed requests (area/line, green) - - Denied requests (area/line, red) + - Blocked requests (area/line, red) - Total requests trend line - X-axis: Date (last 30 days) - Y-axis: Request count @@ -769,17 +769,17 @@ jobs: ``` The audit tool returns structured firewall analysis data including: - - Total requests, allowed requests, denied requests - - Lists of allowed and denied domains + - Total requests, allowed requests, blocked requests + - Lists of allowed and blocked domains - Request statistics per domain **Example of extracting firewall data from audit result:** ```javascript // From the audit tool result, access: - result.firewall_analysis.denied_domains // Array of denied domain names + result.firewall_analysis.blocked_domains // Array of blocked domain names result.firewall_analysis.allowed_domains // Array of allowed domain names result.firewall_analysis.total_requests // Total number of network requests - result.firewall_analysis.denied_requests // Number of denied requests + result.firewall_analysis.blocked_requests // Number of blocked requests ``` **Important:** Do NOT manually download and parse firewall log files. Always use the `audit` tool which provides structured firewall analysis data. @@ -789,22 +789,22 @@ jobs: Use the JSON output from the `audit` tool to extract firewall information. The `firewall_analysis` field in the audit JSON contains: - `total_requests` - Total number of network requests - `allowed_requests` - Count of allowed requests - - `denied_requests` - Count of denied/blocked requests + - `blocked_requests` - Count of blocked requests - `allowed_domains` - Array of unique allowed domains - - `denied_domains` - Array of unique denied/blocked domains - - `requests_by_domain` - Object mapping domains to request statistics (allowed/denied counts) + - `blocked_domains` - Array of unique blocked domains + - `requests_by_domain` - Object mapping domains to request statistics (allowed/blocked counts) - **Example jq filter for aggregating denied domains:** + **Example jq filter for aggregating blocked domains:** ```bash - # Get only denied domains across multiple runs - gh aw audit --json | jq -r '.firewall_analysis.denied_domains[]? // empty' + # Get only blocked domains across multiple runs + gh aw audit --json | jq -r '.firewall_analysis.blocked_domains[]? // empty' - # Get denied domain statistics with counts + # Get blocked domain statistics with counts gh aw audit --json | jq -r ' .firewall_analysis.requests_by_domain // {} | to_entries[] | - select(.value.denied > 0) | - "\(.key): \(.value.denied) denied, \(.value.allowed) allowed" + select(.value.blocked > 0) | + "\(.key): \(.value.blocked) blocked, \(.value.allowed) allowed" ' ``` @@ -813,21 +813,21 @@ jobs: 2. Track the following metrics per workflow: - Total requests (from `total_requests`) - Allowed requests count (from `allowed_requests`) - - Denied requests count (from `denied_requests`) - - List of unique denied domains (from `denied_domains`) + - Blocked requests count (from `blocked_requests`) + - List of unique blocked domains (from `blocked_domains`) - Domain-level statistics (from `requests_by_domain`) ### Step 4: Aggregate Results Combine data from all workflows: - 1. Create a master list of all denied domains across all workflows + 1. Create a master list of all blocked domains across all workflows 2. Track how many times each domain was blocked 3. Track which workflows blocked which domains 4. Calculate overall statistics: - Total workflows analyzed - Total runs analyzed - - Total denied domains (unique) - - Total denied requests + - Total blocked domains (unique) + - Total blocked requests ### Step 5: Generate Report @@ -837,9 +837,17 @@ jobs: - Date of report (today's date) - Total workflows analyzed - Total runs analyzed - - Total unique denied domains - - Total denied requests - - Percentage of denied vs allowed traffic + - Total network requests monitored + - βœ… **Allowed**: Count of successful requests + - 🚫 **Blocked**: Count of blocked requests + - **Block rate**: Percentage of blocked requests (blocked / total * 100) + - Total unique blocked domains + + > **Terminology Note**: + > - **Allowed requests** = Requests that successfully reached their destination + > - **Blocked requests** = Requests that were prevented by the firewall + > - A 0% block rate with listed blocked domains indicates domains that would + > be blocked if accessed, but weren't actually accessed during this period #### 2. Top Blocked Domains A table showing the most frequently blocked domains: @@ -855,7 +863,7 @@ jobs: - Workflow name - Number of unique blocked domains - List of blocked domains - - Total denied requests for this workflow + - Total blocked requests for this workflow #### 4. Complete Blocked Domains List An alphabetically sorted list of all unique blocked domains with: diff --git a/.github/workflows/docs-quality-maintenance-project67.campaign.lock.yml b/.github/workflows/docs-quality-maintenance-project67.campaign.lock.yml index 6e19f61889..368ce6dc05 100644 --- a/.github/workflows/docs-quality-maintenance-project67.campaign.lock.yml +++ b/.github/workflows/docs-quality-maintenance-project67.campaign.lock.yml @@ -269,6 +269,50 @@ jobs: }, "name": "add_comment" }, + { + "description": "Create a status update on a GitHub Projects v2 board. Status updates provide stakeholder communication and historical record of project progress with a timeline. Requires project URL, status indicator, dates, and markdown body describing progress/trends/findings.", + "inputSchema": { + "additionalProperties": false, + "properties": { + "body": { + "description": "Status update body in markdown format describing progress, findings, trends, and next steps. Should provide stakeholders with clear understanding of project state.", + "type": "string" + }, + "project": { + "description": "Full GitHub project URL (e.g., 'https://github.com/orgs/myorg/projects/42' or 'https://github.com/users/username/projects/5'). Project names or numbers alone are NOT accepted.", + "pattern": "^https://github\\.com/(orgs|users)/[^/]+/projects/\\d+$", + "type": "string" + }, + "start_date": { + "description": "Optional project start date in YYYY-MM-DD format (e.g., '2026-01-06').", + "pattern": "^\\d{4}-\\d{2}-\\d{2}$", + "type": "string" + }, + "status": { + "description": "Status indicator for the project. Defaults to ON_TRACK. Values: ON_TRACK (progressing well), AT_RISK (has issues/blockers), OFF_TRACK (significantly behind), COMPLETE (finished), INACTIVE (paused/cancelled).", + "enum": [ + "ON_TRACK", + "AT_RISK", + "OFF_TRACK", + "COMPLETE", + "INACTIVE" + ], + "type": "string" + }, + "target_date": { + "description": "Optional project target/end date in YYYY-MM-DD format (e.g., '2026-12-31').", + "pattern": "^\\d{4}-\\d{2}-\\d{2}$", + "type": "string" + } + }, + "required": [ + "project", + "body" + ], + "type": "object" + }, + "name": "create_project_status_update" + }, { "description": "Report that a tool or capability needed to complete the task is not available. Use this when you cannot accomplish what was requested because the required functionality is missing or access is restricted.", "inputSchema": { @@ -866,14 +910,33 @@ jobs: ### Phase 4 β€” Report & Status Update - 11) Create a project status update summarizing this run: - - Use `create-project-status-update` safe output - - Include campaign summary (tasks completed, in progress, blocked) - - Highlight key findings from the discovery phase - - Document trends and velocity metrics - - Outline next steps and remaining work + 11) **REQUIRED: Create a project status update summarizing this run** + + Every campaign run MUST create a status update using `create-project-status-update` safe output. This is the primary communication mechanism for conveying campaign progress to stakeholders. + + **Required Sections:** + + - **Most Important Findings**: Highlight the 2-3 most critical discoveries, insights, or blockers from this run + - **What Was Learned**: Document key learnings, patterns observed, or insights gained during this run + - **KPI Trends**: Report progress on EACH campaign KPI (Documentation coverage of features, Documentation accessibility score, User-reported documentation issues) with baseline β†’ current β†’ target format, including direction and velocity + - **Campaign Summary**: Tasks completed, in progress, blocked, and overall completion percentage + - **Next Steps**: Clear action items and priorities for the next run + + **Configuration:** - Set appropriate status: ON_TRACK, AT_RISK, OFF_TRACK, or COMPLETE - Use today's date for start_date and target_date (or appropriate future date for target) + - Body must be comprehensive yet concise (target: 200-400 words) + + + **Campaign KPIs to Report:** + + - **Documentation coverage of features** (primary): baseline 85 percent β†’ target 95 percent over 90 days (increase) + + - **Documentation accessibility score** (supporting): baseline 90 percent β†’ target 98 percent over 30 days (increase) + + - **User-reported documentation issues** (supporting): baseline 15 count β†’ target 5 count over 30 days (decrease) + + Example status update: ```yaml @@ -889,15 +952,41 @@ jobs: **Processed:** 10 items added to project, 5 updated **Completion:** 60% (30/50 total tasks) - ### Key Findings - - Documentation coverage improved to 88% - - 3 critical accessibility issues identified - - Worker velocity: 1.2 items/day + ## Most Important Findings + + 1. **Critical accessibility gaps identified**: 3 high-severity accessibility issues discovered in mobile navigation, requiring immediate attention + 2. **Documentation coverage acceleration**: Achieved 5% improvement in one week (best velocity so far) + 3. **Worker efficiency improving**: daily-doc-updater now processing 40% more items per run + + ## What Was Learned + + - Multi-device testing reveals issues that desktop-only testing misses - should be prioritized + - Documentation updates tied to code changes have higher accuracy and completeness + - Users report fewer issues when examples include error handling patterns + + ## KPI Trends + + **Documentation Coverage** (Primary KPI): + - Baseline: 85% β†’ Current: 88% β†’ Target: 95% + - Direction: ↑ Increasing (+3% this week, +1% velocity/week) + - Status: ON TRACK - At current velocity, will reach 95% in 7 weeks + + **Accessibility Score** (Supporting KPI): + - Baseline: 90% β†’ Current: 91% β†’ Target: 98% + - Direction: ↑ Increasing (+1% this month) + - Status: AT RISK - Slower progress than expected, may need dedicated focus - ### Next Steps - - Continue processing remaining 15 items - - Address blocked items in next run - - Target 95% documentation coverage by end of month + **User-Reported Issues** (Supporting KPI): + - Baseline: 15/month β†’ Current: 12/month β†’ Target: 5/month + - Direction: ↓ Decreasing (-3 this month, -20% velocity) + - Status: ON TRACK - Trending toward target + + ## Next Steps + + 1. Address 3 critical accessibility issues identified this run (high priority) + 2. Continue processing remaining 15 discovered items + 3. Focus on accessibility improvements to accelerate supporting KPI + 4. Maintain current documentation coverage velocity ``` 12) Report: @@ -1013,6 +1102,12 @@ jobs: size: "Medium" start_date: "2025-12-15" end_date: "2026-01-03" + PROMPT_EOF + - name: Append prompt (part 2) + env: + GH_AW_PROMPT: /tmp/gh-aw/aw-prompts/prompt.txt + run: | + cat << 'PROMPT_EOF' >> "$GH_AW_PROMPT" ``` --- @@ -1094,12 +1189,6 @@ jobs: ## 10) Parent / Sub-Issue Rules (Campaign Hierarchy) - PROMPT_EOF - - name: Append prompt (part 2) - env: - GH_AW_PROMPT: /tmp/gh-aw/aw-prompts/prompt.txt - run: | - cat << 'PROMPT_EOF' >> "$GH_AW_PROMPT" - Each project board MUST have exactly **one Epic issue** representing the campaign. - The Epic issue MUST: - Be added to the project board diff --git a/.github/workflows/file-size-reduction-project71.campaign.lock.yml b/.github/workflows/file-size-reduction-project71.campaign.lock.yml index 35fce7bc27..9bea6abfae 100644 --- a/.github/workflows/file-size-reduction-project71.campaign.lock.yml +++ b/.github/workflows/file-size-reduction-project71.campaign.lock.yml @@ -269,6 +269,50 @@ jobs: }, "name": "add_comment" }, + { + "description": "Create a status update on a GitHub Projects v2 board. Status updates provide stakeholder communication and historical record of project progress with a timeline. Requires project URL, status indicator, dates, and markdown body describing progress/trends/findings.", + "inputSchema": { + "additionalProperties": false, + "properties": { + "body": { + "description": "Status update body in markdown format describing progress, findings, trends, and next steps. Should provide stakeholders with clear understanding of project state.", + "type": "string" + }, + "project": { + "description": "Full GitHub project URL (e.g., 'https://github.com/orgs/myorg/projects/42' or 'https://github.com/users/username/projects/5'). Project names or numbers alone are NOT accepted.", + "pattern": "^https://github\\.com/(orgs|users)/[^/]+/projects/\\d+$", + "type": "string" + }, + "start_date": { + "description": "Optional project start date in YYYY-MM-DD format (e.g., '2026-01-06').", + "pattern": "^\\d{4}-\\d{2}-\\d{2}$", + "type": "string" + }, + "status": { + "description": "Status indicator for the project. Defaults to ON_TRACK. Values: ON_TRACK (progressing well), AT_RISK (has issues/blockers), OFF_TRACK (significantly behind), COMPLETE (finished), INACTIVE (paused/cancelled).", + "enum": [ + "ON_TRACK", + "AT_RISK", + "OFF_TRACK", + "COMPLETE", + "INACTIVE" + ], + "type": "string" + }, + "target_date": { + "description": "Optional project target/end date in YYYY-MM-DD format (e.g., '2026-12-31').", + "pattern": "^\\d{4}-\\d{2}-\\d{2}$", + "type": "string" + } + }, + "required": [ + "project", + "body" + ], + "type": "object" + }, + "name": "create_project_status_update" + }, { "description": "Report that a tool or capability needed to complete the task is not available. Use this when you cannot accomplish what was requested because the required functionality is missing or access is restricted.", "inputSchema": { @@ -865,14 +909,31 @@ jobs: ### Phase 4 β€” Report & Status Update - 11) Create a project status update summarizing this run: - - Use `create-project-status-update` safe output - - Include campaign summary (tasks completed, in progress, blocked) - - Highlight key findings from the discovery phase - - Document trends and velocity metrics - - Outline next steps and remaining work + 11) **REQUIRED: Create a project status update summarizing this run** + + Every campaign run MUST create a status update using `create-project-status-update` safe output. This is the primary communication mechanism for conveying campaign progress to stakeholders. + + **Required Sections:** + + - **Most Important Findings**: Highlight the 2-3 most critical discoveries, insights, or blockers from this run + - **What Was Learned**: Document key learnings, patterns observed, or insights gained during this run + - **KPI Trends**: Report progress on EACH campaign KPI (Files reduced to target size, Test coverage maintained) with baseline β†’ current β†’ target format, including direction and velocity + - **Campaign Summary**: Tasks completed, in progress, blocked, and overall completion percentage + - **Next Steps**: Clear action items and priorities for the next run + + **Configuration:** - Set appropriate status: ON_TRACK, AT_RISK, OFF_TRACK, or COMPLETE - Use today's date for start_date and target_date (or appropriate future date for target) + - Body must be comprehensive yet concise (target: 200-400 words) + + + **Campaign KPIs to Report:** + + - **Files reduced to target size** (primary): baseline 0 percent β†’ target 100 percent over 90 days (increase) + + - **Test coverage maintained** (supporting): baseline 80 percent β†’ target 80 percent over 7 days (increase) + + Example status update: ```yaml @@ -888,15 +949,41 @@ jobs: **Processed:** 10 items added to project, 5 updated **Completion:** 60% (30/50 total tasks) - ### Key Findings - - Documentation coverage improved to 88% - - 3 critical accessibility issues identified - - Worker velocity: 1.2 items/day + ## Most Important Findings + + 1. **Critical accessibility gaps identified**: 3 high-severity accessibility issues discovered in mobile navigation, requiring immediate attention + 2. **Documentation coverage acceleration**: Achieved 5% improvement in one week (best velocity so far) + 3. **Worker efficiency improving**: daily-doc-updater now processing 40% more items per run + + ## What Was Learned + + - Multi-device testing reveals issues that desktop-only testing misses - should be prioritized + - Documentation updates tied to code changes have higher accuracy and completeness + - Users report fewer issues when examples include error handling patterns + + ## KPI Trends + + **Documentation Coverage** (Primary KPI): + - Baseline: 85% β†’ Current: 88% β†’ Target: 95% + - Direction: ↑ Increasing (+3% this week, +1% velocity/week) + - Status: ON TRACK - At current velocity, will reach 95% in 7 weeks + + **Accessibility Score** (Supporting KPI): + - Baseline: 90% β†’ Current: 91% β†’ Target: 98% + - Direction: ↑ Increasing (+1% this month) + - Status: AT RISK - Slower progress than expected, may need dedicated focus - ### Next Steps - - Continue processing remaining 15 items - - Address blocked items in next run - - Target 95% documentation coverage by end of month + **User-Reported Issues** (Supporting KPI): + - Baseline: 15/month β†’ Current: 12/month β†’ Target: 5/month + - Direction: ↓ Decreasing (-3 this month, -20% velocity) + - Status: ON TRACK - Trending toward target + + ## Next Steps + + 1. Address 3 critical accessibility issues identified this run (high priority) + 2. Continue processing remaining 15 discovered items + 3. Focus on accessibility improvements to accelerate supporting KPI + 4. Maintain current documentation coverage velocity ``` 12) Report: @@ -1034,6 +1121,12 @@ jobs: campaign_id: "file-size-reduction-project71" content_type: "issue" # or "pull_request" content_number: 123 + PROMPT_EOF + - name: Append prompt (part 2) + env: + GH_AW_PROMPT: /tmp/gh-aw/aw-prompts/prompt.txt + run: | + cat << 'PROMPT_EOF' >> "$GH_AW_PROMPT" fields: status: "Done" ``` @@ -1106,12 +1199,6 @@ jobs: - PRs MUST reference their related issue via standard GitHub linking (e.g. β€œCloses #123”). - Worker grouping MUST be done via the `worker_workflow` project field, not via parent issues. - PROMPT_EOF - - name: Append prompt (part 2) - env: - GH_AW_PROMPT: /tmp/gh-aw/aw-prompts/prompt.txt - run: | - cat << 'PROMPT_EOF' >> "$GH_AW_PROMPT" - The Epic issue is narrative only. - The project board is the sole authoritative source of campaign state. diff --git a/pkg/campaign/prompts/orchestrator_instructions.md b/pkg/campaign/prompts/orchestrator_instructions.md index b31498be06..789d439320 100644 --- a/pkg/campaign/prompts/orchestrator_instructions.md +++ b/pkg/campaign/prompts/orchestrator_instructions.md @@ -193,14 +193,29 @@ and synchronizing campaign state into a GitHub Project board. ### Phase 4 β€” Report & Status Update -11) Create a project status update summarizing this run: -- Use `create-project-status-update` safe output -- Include campaign summary (tasks completed, in progress, blocked) -- Highlight key findings from the discovery phase -- Document trends and velocity metrics -- Outline next steps and remaining work +11) **REQUIRED: Create a project status update summarizing this run** + +Every campaign run MUST create a status update using `create-project-status-update` safe output. This is the primary communication mechanism for conveying campaign progress to stakeholders. + +**Required Sections:** + +- **Most Important Findings**: Highlight the 2-3 most critical discoveries, insights, or blockers from this run +- **What Was Learned**: Document key learnings, patterns observed, or insights gained during this run +- **KPI Trends**: Report progress on EACH campaign KPI{{ if .KPIs }} ({{ range $i, $kpi := .KPIs }}{{if $i}}, {{end}}{{ $kpi.Name }}{{end}}){{ end }} with baseline β†’ current β†’ target format, including direction and velocity +- **Campaign Summary**: Tasks completed, in progress, blocked, and overall completion percentage +- **Next Steps**: Clear action items and priorities for the next run + +**Configuration:** - Set appropriate status: ON_TRACK, AT_RISK, OFF_TRACK, or COMPLETE - Use today's date for start_date and target_date (or appropriate future date for target) +- Body must be comprehensive yet concise (target: 200-400 words) + +{{ if .KPIs }} +**Campaign KPIs to Report:** +{{ range .KPIs }} +- **{{ .Name }}**{{ if .Priority }} ({{ .Priority }}){{ end }}: baseline {{ .Baseline }}{{ if .Unit }} {{ .Unit }}{{ end }} β†’ target {{ .Target }}{{ if .Unit }} {{ .Unit }}{{ end }} over {{ .TimeWindowDays }} days{{ if .Direction }} ({{ .Direction }}){{ end }} +{{ end }} +{{ end }} Example status update: ```yaml @@ -216,15 +231,41 @@ create-project-status-update: **Processed:** 10 items added to project, 5 updated **Completion:** 60% (30/50 total tasks) - ### Key Findings - - Documentation coverage improved to 88% - - 3 critical accessibility issues identified - - Worker velocity: 1.2 items/day + ## Most Important Findings + + 1. **Critical accessibility gaps identified**: 3 high-severity accessibility issues discovered in mobile navigation, requiring immediate attention + 2. **Documentation coverage acceleration**: Achieved 5% improvement in one week (best velocity so far) + 3. **Worker efficiency improving**: daily-doc-updater now processing 40% more items per run + + ## What Was Learned + + - Multi-device testing reveals issues that desktop-only testing misses - should be prioritized + - Documentation updates tied to code changes have higher accuracy and completeness + - Users report fewer issues when examples include error handling patterns + + ## KPI Trends + + **Documentation Coverage** (Primary KPI): + - Baseline: 85% β†’ Current: 88% β†’ Target: 95% + - Direction: ↑ Increasing (+3% this week, +1% velocity/week) + - Status: ON TRACK - At current velocity, will reach 95% in 7 weeks + + **Accessibility Score** (Supporting KPI): + - Baseline: 90% β†’ Current: 91% β†’ Target: 98% + - Direction: ↑ Increasing (+1% this month) + - Status: AT RISK - Slower progress than expected, may need dedicated focus + + **User-Reported Issues** (Supporting KPI): + - Baseline: 15/month β†’ Current: 12/month β†’ Target: 5/month + - Direction: ↓ Decreasing (-3 this month, -20% velocity) + - Status: ON TRACK - Trending toward target + + ## Next Steps - ### Next Steps - - Continue processing remaining 15 items - - Address blocked items in next run - - Target 95% documentation coverage by end of month + 1. Address 3 critical accessibility issues identified this run (high priority) + 2. Continue processing remaining 15 discovered items + 3. Focus on accessibility improvements to accelerate supporting KPI + 4. Maintain current documentation coverage velocity ``` 12) Report: