🤖 Kelos Self-Update Agent @gjkim42
Area: Workflow Completeness
Summary
self-development/README.md lines 418–425 carry a table titled "Webhook filter fields the shipped self-development spawners rely on". The table has two opposite drift problems:
- It documents
excludeBodyPatterns — which no shipped self-development/*.yaml spawner actually uses.
- It omits
state, action, labels, and excludeLabels — all of which ARE used by shipped spawners, and three of which appear in the README's own example block immediately above the table.
A reader who copies from the table cannot reproduce the shipped patterns; a reader who copies from the example finds three field names (action, labels, state) that the table never explains. Either surface is incomplete on its own.
This is a self-contained README finding distinct from the other open self-development-README issues (#1019, #1109, #1207, #1226) — none of them mention the filter-fields reference table introduced by PR #1178.
Findings
1. excludeBodyPatterns is documented but unused by every shipped spawner
README.md line 422:
excludeBodyPatterns | TaskSpawner.spec.when.githubWebhook.filters[] | Companion to bodyPattern: a list of regexes that, if any match, drop the event…
Search across every shipped self-development spawner:
$ grep -n excludeBodyPatterns self-development/*.yaml
(no matches)
None of the 11 shipped spawners (kelos-api-reviewer.yaml, kelos-config-update.yaml, kelos-fake-strategist.yaml, kelos-fake-user.yaml, kelos-image-update.yaml, kelos-planner.yaml, kelos-pr-responder.yaml, kelos-reviewer.yaml, kelos-self-update.yaml, kelos-squash-commits.yaml, kelos-triage.yaml, kelos-workers.yaml) use this field. The table's stated scope is "fields the shipped self-development spawners rely on" — by that contract, the row should not be there.
2. Four heavily used fields are absent from the table
state — used by every webhook spawner (always state: open):
kelos-api-reviewer.yaml:53,58kelos-planner.yaml:39kelos-pr-responder.yaml:19,24kelos-reviewer.yaml:52,57kelos-squash-commits.yaml:17,22kelos-triage.yaml:16,23kelos-workers.yaml:69
action — used by every webhook spawner (created, submitted, opened, reopened). The table currently has no row for it, so a reader cannot tell whether the example's action: created is required or optional, or what other values are legal.
labels — used by kelos-triage.yaml:19–20 (labels: [needs-actor]) to gate the reopened action.
excludeLabels — used by kelos-triage.yaml:14–15 and 21–22 (excludeLabels: [triage-accepted]) to prevent re-triage.
3. The example block uses three of the missing fields
The example YAML immediately above the table (lines 397–414) uses action, labels, and state:
spec:
when:
githubWebhook:
repository: your-org/your-repo
excludeAuthors:
- your-bot[bot] # avoid self-trigger loops
events: [issue_comment]
filters:
- event: issue_comment
action: created # ← not in table
bodyPattern: /kelos pick-up
commentOn: Issue
author: your-maintainer
labels: [your-label] # ← not in table
state: open # ← not in tableSo the README presents these field names in the canonical example, then catalogs every other field in the example except those three. The table cannot serve as a reference for the example it sits under.
Impact
A user adapting the shipped patterns to their repo will encounter action, labels, state, or excludeLabels (because they're in the example or in the spawner they're copying), look up the table, find no explanation, and have to leave the README for docs/reference.md. The table's purpose — saving that lookup for the shipped-pattern subset — is partly defeated. Meanwhile, the excludeBodyPatterns row sends users hunting for a usage example in the shipped spawners that doesn't exist.
Proposed fix
Update the table at self-development/README.md lines 418–425:
- Remove the
excludeBodyPatterns row (no shipped spawner uses it; readers wanting it can find it in docs/reference.md).
- Add rows for the four missing fields, all of which live in
TaskSpawner.spec.when.githubWebhook.filters[]:
action — Required per filter. Names which webhook action this filter matches (e.g., created for issue_comment, submitted for pull_request_review, opened/reopened for issues).state — Match by issue/PR state (open, closed). Every shipped webhook spawner sets open so closed items don't retrigger after the fact.labels — Require the issue/PR to carry all listed labels. Used by kelos-triage to gate reopened events on needs-actor.excludeLabels — Drop events whose issue/PR carries any listed label. Used by kelos-triage to skip already-triaged issues (triage-accepted).
Optionally, also add events (top-level) — every webhook spawner declares it (e.g., [issue_comment], [issue_comment, pull_request_review], [issues]), and it appears in the example.
Not covered by existing issues
🤖 Kelos Self-Update Agent @gjkim42
Area: Workflow Completeness
Summary
self-development/README.mdlines 418–425 carry a table titled "Webhook filter fields the shipped self-development spawners rely on". The table has two opposite drift problems:excludeBodyPatterns— which no shippedself-development/*.yamlspawner actually uses.state,action,labels, andexcludeLabels— all of which ARE used by shipped spawners, and three of which appear in the README's own example block immediately above the table.A reader who copies from the table cannot reproduce the shipped patterns; a reader who copies from the example finds three field names (
action,labels,state) that the table never explains. Either surface is incomplete on its own.This is a self-contained README finding distinct from the other open self-development-README issues (#1019, #1109, #1207, #1226) — none of them mention the filter-fields reference table introduced by PR #1178.
Findings
1.
excludeBodyPatternsis documented but unused by every shipped spawnerREADME.mdline 422:Search across every shipped self-development spawner:
None of the 11 shipped spawners (
kelos-api-reviewer.yaml,kelos-config-update.yaml,kelos-fake-strategist.yaml,kelos-fake-user.yaml,kelos-image-update.yaml,kelos-planner.yaml,kelos-pr-responder.yaml,kelos-reviewer.yaml,kelos-self-update.yaml,kelos-squash-commits.yaml,kelos-triage.yaml,kelos-workers.yaml) use this field. The table's stated scope is "fields the shipped self-development spawners rely on" — by that contract, the row should not be there.2. Four heavily used fields are absent from the table
state— used by every webhook spawner (alwaysstate: open):kelos-api-reviewer.yaml:53,58kelos-planner.yaml:39kelos-pr-responder.yaml:19,24kelos-reviewer.yaml:52,57kelos-squash-commits.yaml:17,22kelos-triage.yaml:16,23kelos-workers.yaml:69action— used by every webhook spawner (created,submitted,opened,reopened). The table currently has no row for it, so a reader cannot tell whether the example'saction: createdis required or optional, or what other values are legal.labels— used bykelos-triage.yaml:19–20 (labels: [needs-actor]) to gate thereopenedaction.excludeLabels— used bykelos-triage.yaml:14–15 and 21–22 (excludeLabels: [triage-accepted]) to prevent re-triage.3. The example block uses three of the missing fields
The example YAML immediately above the table (lines 397–414) uses
action,labels, andstate:So the README presents these field names in the canonical example, then catalogs every other field in the example except those three. The table cannot serve as a reference for the example it sits under.
Impact
A user adapting the shipped patterns to their repo will encounter
action,labels,state, orexcludeLabels(because they're in the example or in the spawner they're copying), look up the table, find no explanation, and have to leave the README fordocs/reference.md. The table's purpose — saving that lookup for the shipped-pattern subset — is partly defeated. Meanwhile, theexcludeBodyPatternsrow sends users hunting for a usage example in the shipped spawners that doesn't exist.Proposed fix
Update the table at
self-development/README.mdlines 418–425:excludeBodyPatternsrow (no shipped spawner uses it; readers wanting it can find it indocs/reference.md).TaskSpawner.spec.when.githubWebhook.filters[]:action— Required per filter. Names which webhook action this filter matches (e.g.,createdforissue_comment,submittedforpull_request_review,opened/reopenedforissues).state— Match by issue/PR state (open,closed). Every shipped webhook spawner setsopenso closed items don't retrigger after the fact.labels— Require the issue/PR to carry all listed labels. Used bykelos-triageto gatereopenedevents onneeds-actor.excludeLabels— Drop events whose issue/PR carries any listed label. Used bykelos-triageto skip already-triaged issues (triage-accepted).Optionally, also add
events(top-level) — every webhook spawner declares it (e.g.,[issue_comment],[issue_comment, pull_request_review],[issues]), and it appears in the example.Not covered by existing issues
make testclaim on line 88) — none of them touch the filter-fields table at lines 418–425.kelos-pr-responder's missinglabels: [generated-by-kelos]filter and the README text describing it — about the spawner, not the reference table.