Katenary/katenarycli-tool

Audited from a 0k-token evidence dossier; 4 files read, 10 probes answered.

Katenary reads labels off a docker-compose file and emits a working Helm chart, the label vocabulary ^[24] doing the work a full DSL would in a heavier tool. The generator code is readable and narrowly scoped ^[27], but the project has already left GitHub for a self-hosted Gitea mirror ^[24], and the health snapshot behind that mirror is thin.

The central tension is trust in a moving target: a small, capable CLI whose canonical home, contributor base, and issue-tracking discipline are all hard to verify from here.

The main knocks:

• The project has already migrated off GitHub, and this mirror is a read-only shell. The README banner and a CI workflow that auto-rewrites the mirror's README both confirm the real repository, issues, and PRs now live at repo.katenary.io ^[24]. A stale PR-closing bot on this mirror ^[26] means GitHub-side activity metrics are meaningless.
• Issue and contribution health can't be read here at all. The health digest for this mirror shows 0 open issues and unknown response/close times ^[25], which is a mirror artifact, not evidence the upstream project is quiet.
• Contributor concentration is total. Seven contributors with 100% top-10 concentration ^[25] means bus factor risk sits with effectively one maintainer, a real concern for a tool teams would wire into a deploy pipeline.
• The dependency scan surfaces unresolved high-severity findings. Two high-severity CVEs turn up in the lockfile-resolved scan ^[18] with no visible engagement in the dossier's evidence, which is the kind of gap that should cost points rather than be waved off.

What holds up:

• The label-driven conversion model is a coherent fit for the problem. Rather than inventing a new config format, Katenary layers Kubernetes concerns (ingress, cronjobs, secrets) onto existing compose labels ^[27], keeping the common path label-free per the README ^[24].
• The generator code reads cleanly for its size. Ingress and CronJob generation are self-contained, single-purpose files with clear Yaml()/Filename() interfaces ^[27], and the most graph-central file is directly exercised by tests ^[17].
• Test coverage of utility logic is real, not decorative. Table-driven Go tests with genuine assertions cover the templating and naming helpers ^[28], and the broader assertion probe finds real checks across 30 test files ^[16].
• Distribution is taken seriously for a CLI. Linux package repos, a Windows installer, and a documented install script all ship alongside binary releases ^[24], lowering the discovery-to-first-success cost this archetype is judged on.

A capable, well-scoped compose-to-Helm converter, but this GitHub copy is a dead mirror of a project whose real health lives elsewhere.

Consider Helm's own `helm create` scaffolding or Kompose for compose-to-Kubernetes conversion as lower-lock-in baselines.