Refine Outcome Collector executive report layout and shift cadence to 3-day runs

[Copilot]

This updates Outcome Collector reporting so decision-driving content is visible immediately: action items now appear at root level under the executive summary, and each workflow row now includes status-scoped reference links for fast verification. It also reduces run frequency from 6-hour cadence to every 3 days.

• Executive section restructuring

  • Moves 🔴 Action Items out of the collapsible details block and places it directly under the executive summary table.
  • Keeps detailed metrics/trends in <details> while preserving an executive-first read path.

• Workflow table enrichment

  • Adds a References column to the executive workflow table.
  • Defines compact, status-grouped link formatting for accepted/rejected/pending/ignored/unknown outcomes.
  • Requires real identifiers in link labels (issue/PR/discussion/comment number, run ID, or short SHA), not synthetic counters.

• Cadence change

  • Updates workflow schedule from every 6 hours to every 3 days (0 0 */3 * *).

| Workflow | Status | Lifecycle health | References |
|---|---|---|---|
| {workflow_name} | <span style="white-space: nowrap;">{status_bar}</span> | {lifecycle_emoji} {lifecycle_label} | A: [#123](...) · R: [#78](...) · P: [#90](...) |

[Copilot]

Pull request overview

This PR restructures the Outcome Collector report so action items appear directly under the executive summary, adds a References column with status-grouped links to the workflow table, and reduces run cadence from every 6 hours to every 3 days.

Changes:

• Move 🔴 Action Items out of <details> and place under the executive summary table.
• Add References column with grouped status links (A/R/P/etc.) and formatting rules.
• Change schedule from 54 */6 * * * to 0 0 */3 * * (every 3 days).

Show a summary per file

File	Description
.github/workflows/outcome-collector.md	Restructures report layout, adds References column rules, updates cron cadence.
.github/workflows/outcome-collector.lock.yml	Regenerated compiled workflow reflecting source .md changes.

Copilot's findings

Tip

Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

• Files reviewed: 2/2 changed files
• Comments generated: 0

[github-actions]

🧪 Test Quality Sentinel completed test quality analysis.

No test files were added or modified in this PR. The PR only changes .github/workflows/outcome-collector.md and .github/workflows/outcome-collector.lock.yml (workflow definition files). Test Quality Sentinel skipped.

[github-actions]

✅ PR Code Quality Reviewer completed the code quality review.

[github-actions]

🧠 Matt Pocock Skills Reviewer has completed the skills-based review. ✅

[github-actions]

✅ Design Decision Gate 🏗️ completed the design decision gate check.

No ADR enforcement needed: PR #35748 does not have the 'implementation' label (has_implementation_label=false) and has 0 new lines of code in business logic directories (≤100 threshold; requires_adr_by_default_volume=false). The changed files are skill shell/python scripts and a shared MCP server script, none in default business-logic directories.

[github-actions]

Review: Outcome Collector report restructuring

No blocking issues. The restructuring (Action Items promoted out of <details>, References column added, cadence reduced) is coherent and well-specified.

⚠️ Minor: cron schedule is not exactly every 72 hours

The new schedule 0 0 */3 * * runs on days 1, 4, 7, 10 ... of each month. At month boundaries the actual interval varies — end-of-month to start-of-next-month can be 1–3 days instead of 3. The comment says "every 3 days" which is approximately right but imprecise. If alignment to calendar days is the intent this is fine; if strictly every-72h is needed, consider a UTC-anchored approach or just accept the approximation.

This doesn't affect correctness — just a heads-up on the semantics.

🔎 Code quality review by PR Code Quality Reviewer · sonnet46 656.8K

[github-actions]

Skills-Based Review 🧠

Applied /zoom-out — approving with two minor suggestions.

📋 Key Themes & Highlights

Key Themes

• References prefix ambiguity: The A: R: P: shorthand is used in the example but the mapping for ignored and unknown isn't defined, leaving room for agent-generated inconsistency across runs.
• Cron offset removed: New schedule fires at 00:00 exactly; the original was intentionally scattered. Low risk but worth a conscious choice.

Positive Highlights

• ✅ Moving �� Action Items out of <details> is exactly the right UX decision — decision-driving content should never be buried.
• ✅ References column is a clean additive enrichment with clear rules and a good example.
• ✅ 12× cadence reduction (6 h → 3 days) is a sensible cost/noise trade-off for a reporting workflow.
• ✅ Lock file changes are purely derivative — no manual edits, correctly regenerated.

🧠 Reviewed using Matt Pocock's skills by Matt Pocock Skills Reviewer · sonnet46 1.4M

[github-actions]

[/zoom-out] The status prefix abbreviations (A:, R:, P:) are used in the example but the mapping for all five statuses is never explicitly defined.

The rules list accepted, rejected, pending, ignored, unknown but do not state which single-letter prefix maps to each. An agent could use Ign:, Unk:, I:, U:, or something else, producing inconsistent output across runs.

💡 Suggested fix

Add an explicit mapping line to the References column rules:

- Status prefix key: A = accepted · R = rejected · P = pending · I = ignored · U = unknown

This keeps shorthand concise while removing ambiguity for the generating agent.

[github-actions]

[/zoom-out] The new cron 0 0 */3 * * fires exactly at midnight, whereas the original 54 */6 * * * was intentionally offset to scatter load and avoid collisions with other midnight-aligned scheduled jobs.

This is a minor operational concern rather than a blocker, but worth a deliberate choice.

💡 Options

• Keep 0 0 */3 * * if simplicity and predictability are preferred over load-scattering.
• Or use a small offset (e.g. 15 1 */3 * *) to avoid the midnight pile-up common in scheduled CI workflows.

Either is fine — just making sure the offset removal is intentional rather than accidental.