Epic: Proof-led CI reporting adoption

[lbliii]

Parent saga: #154
Related evidence work: #199

Thesis

Acquire users through a useful CI-reporting outcome, then convert interested teams to checked Kida components. Do not ask teams to replace Jinja wholesale, and do not market unverified performance, security, cold-start, lock-free, or universal static-typing claims.

The wedge is:

useful CI report → maintainable custom report component → checked component calls in CI → broader Kida use

Why now

Kida already ships a composite Kida Report Action with built-in report templates, Markdown/PR-comment output, and typed report boundaries. Marketplace publication and external dogfooding are prepared but not yet evidenced. The public product position is “server-side components for Python,” with static call-site validation as a supporting proof—not a generic Jinja replacement pitch.

Raw signals and confidence

Signal	Confidence	Implication
Kida’s Action, report templates, fixtures, and Marketplace guide are present and self-dogfooded	High	CI reports are the lowest-friction first-use product
kida check --validate-calls catches unknown/missing component parameters and literal mismatches before render	High	A fair, demonstrable component-contract story exists
Jinja users report runtime/context and undefined-value failures	Medium	Use a sourced corpus to select reproducible examples; do not generalize from anecdotes
Existing report Actions expose deep, mature output/OS-specific capabilities	High	Compare capability and tradeoffs, never claim a universal replacement
Python 3.14t interest produces broad adoption by itself	Low	Treat free-threading as evidence for an expert segment, not the acquisition headline

Decision

Use a three-fixture evidence program before broad launch or public “vs. Jinja” claims:

1. Component-call typo: compare Kida static validation with Jinja configured using best-practice StrictUndefined; distinguish check-time findings from dynamic-runtime failures.
2. Custom CI report: compare a conventional inline/scripted workflow with a Kida component/template workflow; measure time-to-feedback and maintenance structure, not synthetic speed.
3. Report-action evaluation: compare Kida Report with a mature focused report Action across inputs, output targets, customization, permissions, runner/platform constraints, and limitations.

Every public claim must link to a pinned, runnable fixture and state what Kida does not solve.

Dependencies and sequence

1. #TBD sourced complaint corpus
2. #TBD reproducible fixtures, with output parity before measurement
3. #TBD evidence cards and adoption collateral
4. #TBD Marketplace publication (external-owner gate)
5. #TBD external dogfood pilots (external-write gate)

Tasks 1–3 create evidence. Tasks 4–5 consume it. No external publication, release, or third-party pull request is authorized by this epic.

Steward notes

Consulted for this backlog design: action, analysis, benchmarks, cli, compiler, contrib, docs, environment, examples, github, markdown, nodes, plan, public, readme, schemas, syntax, template, templates, terminal, tests, and utils.

The likely implementation perimeter is action/github/templates/markdown/schemas/utils (reporting) plus analysis/cli/parser/nodes/compiler/template/environment/public (checked component demonstration), benchmarks (only if a claim needs measurement), and tests/examples/site/docs (reproducible collateral). Contrib, readme, and terminal are consulted no-change surfaces unless a selected fixture proves otherwise.

Risks and dissent

• Dissent: broad framework adoption may be a stronger long-term story than DevOps. Preserve Saga: Trojan horse — Kida as server-side components for Python, everywhere #154’s horizontal framework path; this epic tests CI reporting as a wedge, not as Kida’s identity.
• Risk: a default-Jinja comparison is misleading. Require StrictUndefined where applicable and disclose dynamic-data boundaries.
• Risk: competitor comparison turns into performance theater. Require equal output, pinned versions, environment provenance, and an explicit “not solved” section.
• Risk: Marketplace and external PR work cause public/reputational changes. Keep them separately blocked until the repository owner authorizes execution.
• Risk: the report Action is currently Bash-oriented. Record supported runner/platform constraints rather than silently implying universal portability.

Not now

• Rebuilding Ansible, Packer, or general Jinja pipelines.
• A generic “replace Jinja” campaign.
• SaaS, telemetry, a template marketplace, new runtime dependencies, or new language/configuration surfaces.
• Competitive security or linear-scaling claims without separately approved evidence work.
• Moving this epic into status/active while another bounded epic is the execution queue.

Success evidence

• A source-backed corpus classifies at least 20 public pain signals and selects only Kida-addressable cases.
• Three fixtures run from a documented command with pinned versions and output assertions.
• Each published comparison states limitations and has no unsupported headline metric.
• Marketplace publication is verified only after owner authorization.
• Five external pilot PRs are submitted only after owner authorization; track discussions, merges, and 14-day pilot observations separately.

Downstream-pilot classification

No downstream pilot yet: this epic is planning and evidence design. The later dogfood-pilot task must follow docs/downstream-pilot-policy.md and record each target repository, immutable revision, real payload, successful runs, and owner feedback.

[lbliii]

Task roster

• Task: Curate a sourced CI and template-pain corpus #319 — sourced CI/template-pain corpus; selects only evidence-backed, Kida-addressable scenarios.
• Task: Build fair Kida comparison fixtures from selected pain cases #320 — fair runnable fixtures; blocked by Task: Curate a sourced CI and template-pain corpus #319 and related to Epic: Evidence — publish the Jinja2 story per release #199’s release-evidence work.
• Task: Publish evidence cards for verified CI adoption scenarios #321 — evidence cards and adoption collateral; blocked by Task: Build fair Kida comparison fixtures from selected pain cases #320.
• Task: Publish the verified Kida Report Action on GitHub Marketplace #322 — Marketplace publication; blocked on Task: Publish evidence cards for verified CI adoption scenarios #321 and explicit repository-owner release authority.
• Task: Run owner-approved external Kida Report dogfood pilots #323 — external dogfood pilots; blocked on Task: Publish evidence cards for verified CI adoption scenarios #321, Task: Publish the verified Kida Report Action on GitHub Marketplace #322, and fresh owner authority for each outreach campaign.

This ordering deliberately keeps research, fixtures, and public publication separate. The only currently active execution queue remains unchanged.