Workflow Completeness: /kelos api-review is dead in kanon-development and README wrongly claims Kanon has 'no API surface' (Kanon PR #9: maintainer used it, no task fired)

[kelos-bot]

🤖 Kelos Agent @gjkim42

Summary

/kelos api-review is dead in the kanon-development/ workflow — no TaskSpawner matches it — yet the maintainer reaches for it out of habit (carried over from self-development/), and the kanon-development/README.md "Not ported" note wrongly states Kanon has "no … API surface to review." In reality Kanon has a first-class API surface (its CLI commands/flags and the kanon.yaml schema) that the triage, planner, and reviewer prompts all explicitly treat as permanent-once-shipped and requiring special review. The README rationale conflates "no Kubernetes CRDs" with "no API surface," which is inaccurate and risks misleading a maintainer into thinking API concerns are uncovered.

Focus area: Workflow Completeness (gap in agent coverage for a command operators actually use + README accuracy).

Evidence

Kanon PR #9 (kelos-dev/kanon) — maintainer used /kelos api-review, got nothing:

2026-05-31T02:22:33Z  gjkim42     /kelos api-review        <- no task status reply
2026-05-31T02:23:04Z  gjkim42     /kelos review            <- fell back 31s later
2026-05-31T02:23:07Z  kelos-bot   Task kanon-reviewer-... succeeded ✅

The /kelos api-review comment produced no task; only the follow-up /kelos review spawned kanon-reviewer. (bodyPattern: /kelos review does not match /kelos api-review — the literal substring /kelos review is absent.)

No spawner handles it. grep -rn api-review kanon-development/ returns a single hit — the README note below — and no spawner filter:

kanon-development/README.md:44: > **Not ported from `self-development/`:** `kelos-api-reviewer` (Kanon has no
                                  Kubernetes CRDs/API surface to review) ...

The workflow already recognizes a Kanon API surface, contradicting that note:

• kanon-triage.yaml — kind/api: "introduces or changes a user-facing surface: a CLI command or flag, or the kanon.yaml configuration schema." kind/api issues are forced to actor/human and held back from triage-accepted.
• kanon-planner.yaml §3a — "Kanon's user-facing surface — CLI commands and flags, and the kanon.yaml configuration schema — is effectively permanent once shipped."
• kanon-reviewer.yaml §4 — a dedicated "CLI and config surfaces are special" callout flagging misleading names, hard-to-extend shapes, and breaking renames.

So API review is a real concern in Kanon — it is currently folded into kanon-reviewer, not absent.

Proposal (minimal)

Two small, evidence-backed changes — no new speculative spawner required:

1. Make the maintainer's habit work. Add /kelos api-review as an additional bodyPattern filter on kanon-reviewer (alongside /kelos review), so the existing "CLI and config surfaces are special" review section answers it. This is the lowest-friction fix and matches observed maintainer behavior on PR Add axon CLI for managing Tasks #9.

2. Fix the README "Not ported" note. Reword it so it stops claiming Kanon has "no API surface." Suggested replacement:

   Not ported from self-development/: kelos-api-reviewer — Kanon has no Kubernetes CRDs, so there is no separate API-review spawner. Kanon's user-facing API surface (CLI commands/flags and the kanon.yaml schema) is reviewed by kanon-reviewer directly (see its "CLI and config surfaces are special" section), and triaged via the kind/api label. kelos-image-update is also not ported (Kanon has no coding-agent Dockerfiles to bump).

If a maintainer prefers a dedicated agent instead of folding api-review into kanon-reviewer, that is a larger design choice and can be tracked separately; option 1 above is the minimal change that removes the dead command.

Acceptance criteria

• /kelos api-review on a Kanon PR triggers a review (or the README explicitly documents that only /kelos review is wired and /kelos api-review is not supported).
• kanon-development/README.md no longer states Kanon has "no API surface to review"; it accurately describes where CLI/kanon.yaml API review happens.

[kelos-bot]

🤖 Kelos Task Status

Task kelos-triage-issues-607f10543260 has succeeded. ✅

[kelos-bot]

🤖 Kelos Agent @gjkim42

Kelos Triage Report

Kind: kind/bug — a slash command operators actually use (/kelos api-review) silently fires no task, and the README states something the code contradicts.
Priority: priority/important-longterm — real maintainer-workflow gap (observed on Kanon PR #9) plus a doc inaccuracy, but a working fallback exists (/kelos review), so not blocking.
Actor: actor/kelos — concrete, minimal, objectively verifiable scope: add one bodyPattern filter and reword a README note in kanon-development/. This modifies an existing TaskSpawner filter and docs, not a new Kelos CRD/CLI surface, so it is not kind/api.

Status: STILL VALID

Evidence:

• Dead command confirmed. kanon-development/kanon-reviewer.yaml filters only on bodyPattern: /kelos review (lines 48 and 54). The literal substring /kelos review is absent from /kelos api-review (the api- segment breaks it), so the command matches no spawner. grep -rn api-review kanon-development/ returns a single hit — the README note — and no filter.
• README inaccuracy confirmed. kanon-development/README.md:44-46 states kelos-api-reviewer was not ported because "Kanon has no Kubernetes CRDs/API surface to review."
• The workflow already treats Kanon as having an API surface, contradicting that note: kanon-triage.yaml:71-72 defines kind/api as "a CLI command or flag, or the kanon.yaml configuration schema"; kanon-planner.yaml:103 calls that surface "effectively permanent once shipped"; kanon-reviewer.yaml:123-125 has a dedicated "CLI and config surfaces are special" review callout. So API review is folded into kanon-reviewer, not absent.
• Not already fixed / not outdated. No merged PRs (gh pr list --state merged --search 1265 → empty) and no commits (git log --grep=1265 → empty) address this; the cited files still exhibit the behavior on main.

Duplicates found: None found.

• Related but distinct: Configuration Alignment: kanon-reviewer filters drop the worker's own /kelos review — automated worker→reviewer handoff never fires (Kanon PR #6: comment by kelos-bot[bot], 0 reviews) #1250 (kanon-reviewer excludeAuthors: kelos-bot[bot] drops the worker's own /kelos review handoff) — same spawner, different filter defect (author exclusion vs. missing api-review pattern). Workflow Completeness: kelos-workers and kelos-reviewer claim 'generated CRD YAML' lives under api/, but it lives in internal/manifests/ — YAML-only CRD diffs bypass /kelos api-review #1226 and Workflow Completeness: kelos-api-reviewer mandates trailing /kelos needs-input line that has no automation effect #1116 concern /kelos api-review in self-development/, not kanon-development/. None overlap semantically with this issue.

Recommendation: KEEP OPEN — proceed with the issue's minimal Proposal: (1) add /kelos api-review as an additional bodyPattern on kanon-reviewer, and (2) reword the kanon-development/README.md "Not ported" note to stop claiming Kanon has no API surface. The larger "dedicated api-review agent" option is correctly deferred and out of scope here.

[kelos-bot]

🤖 Kelos Task Status

Task kelos-api-reviewer-issue-comment-198da07888d9 has succeeded. ✅