cimpl-report

cimpl-report.md

cimpl-report

---

name: release-demo description: Build a demo-grade interactive HTML dashboard of OSDU release health, Venus scope flow, and engineer activity, with charts and wow-factor visuals, then open it. allowed-tools:

• shell(osdu-quality)
• shell(osdu-activity)
• shell(osdu-engagement)
• shell(glab)
• shell(python)
• shell(Start-Process)
• task
• write

---

Build me an interactive, single-file HTML dashboard on the current OSDU release for a live executive demo. Polish and wow factor, not just tables. Optimize for execution speed: the four data pulls are the only long pole, so overlap everything else with them.

Execution plan (do these concurrently, not in sequence)

1. Fire the data first. If GITLAB_TOKEN is unset, derive it from glab auth status --show-token and capture the full whitespace-delimited token after Token found: (regex Token found:\s*(\S+)). The token contains periods (for example ...CA.01.0y0k...), so do not use a \w/[\w-] class that stops at the first dot. Then launch all four pulls as parallel background jobs within a single shell invocation that both starts the jobs and waits for them (Start-Job ...; Get-Job | Wait-Job): a fire-and-return call is killed when the command exits, so the jobs must be launched and awaited in the same session. Set $env:GITLAB_TOKEN inside each job (env vars do not persist across shell calls). Redirect each job's stdout to its own file (1> name.json, keep stderr separate in name.err, do not pipe through Out-File), and verify each file is non-empty before parsing (a near-empty file plus a 401 in name.err means the token was parsed wrong):

   • osdu-quality release --output json -> per-service acceptance %, coverage, Sonar R/S/M, quality gate, CVE counts, plus aggregates.
   • osdu-activity epic list --label Venus --output json -> data.epics[] with issues[] carrying created_at/closed_at (dated), liveness, linked MR counts.
   • osdu-engagement contribution --days 30 --output json -> data.contributors[] (MRs authored, reviews given, total) and statistics.
   • osdu-activity mr --state opened --include-draft --output json -> data.projects[].merge_requests[] with author and pipeline status; statistics totals. Each tool prints progress before JSON, so slice from the first {.

2. While the pulls run, in parallel:

   • Write the Python transformer + HTML template against the schemas above (do not wait for live values; the field names are stable). Inject computed JSON into one placeholder in the template.
   • Send the design and the scope-flow derivation to the rubber-duck agent as a background task so its critique lands by the time data is ready.

3. Render once the files exist: run the transformer, assert the embedded JSON parses and the placeholder is gone, then open it with Start-Process.

Required design decisions (already vetted, do not re-derive)

• Hero: 3-4 animated count-up KPIs (avg acceptance %, avg coverage %, total critical CVEs, open Venus issues), each with a context subtext (measured/total, gates failing, services affected, active epics), plus a one-sentence auto-generated verdict driven by red-status service count.
• Risks & Watch: top 3 services by a normalized weighted risk score (acceptance 40, critical CVEs 35, high CVEs 15, quality gate 10) with plain-English reasons next to each.
• Scope flow, not burndown: plot cumulative created vs cumulative closed issues (deduped by canonical project_path#iid, falling back to web_url, since URLs drift across host/redirect/migration) with an open-remaining line. Aggregate events per day before computing cumulatives. Any "ideal" line must be dashed and labeled illustrative only, since Venus scope is open-ended. Title it "Venus Scope Flow", never "Burndown".
• CVE stacked bar per service (critical/high/medium), sorted by risk, click-through to the GitLab vulnerability report.
• Contributor bubble (x = MRs authored, y = reviews given, size = total), framed as review load and community activity, not individual performance.
• Service table: sortable/filterable, traffic-light status, R/S/M rating chips, deep links to CI / Sonar / Allure / CVE pages. Print-to-PDF button.
• Treat missing/errored acceptance as a separate "no signal" state, never as 0.

Visuals and constraints

• Chart.js via CDN; otherwise one self-contained .html file, dark theme, responsive, fade-in on scroll.
• Save it to the session files directory and open it.
• Footer notes data freshness (generation timestamp) and caveats: acceptance average covers only services reporting a pass rate; CVE counts are per-service sums and may double-count transitive findings; the MR feed paginates per project so the 30-day contributor aggregate is the authoritative figure; reopened issues are not modeled in the flow.

Follow the repo writing-style rules: no em dashes in any generated prose.