hermes-bot
de080442d3
The owner wants the path alert -> [alert] issue -> kanban card -> expert fix PR -> owner merges, without a human step in between. Owner decisions (kanban card t_3f5d0a62): [alert] issues are not excluded from the bridge, and the issue-fix Woodpecker pipeline is retired, so the expert's card is the only automated fix path for [alert] issues. Routing - alert-monitor: `alerts.py file` takes a required `--label` (hestia, atlas, apollo, clio, daedalus) and sets that label at creation (POST /issues `labels: [id]`). Gitea 1.27.3 adds the labels in the same transaction (services/issue/issue.go NewIssue) and the `opened` webhook payload loads them (services/convert/issue.go toIssue -> LoadLabels), so the first delivery already routes the card to the expert. Org labels are accepted for org repos (models/issues/issue_update.go: label.OrgID == repo.OwnerID). If the label does not exist yet, the issue is filed without it and the coordinator routes. SKILL.md tells the triage agent how to pick the expert. - Label-less issues no longer go to triage. kanban.auto_decompose defaults to true (hermes_cli/config_defaults.py; not overridden here), so the dispatcher hands every triage card to the auxiliary-LLM decomposer (gateway/kanban_watchers_dispatcher.py auto_decompose_tick -> kanban_decompose.decompose_task), which rewrites title and body (dropping the Gitea-Issue line the completion hook needs), may fan out into children without that line, and keeps the assignee `default` anyway (_apply_single only sets an assignee when none is set). The card is now created ready for `default` with routing instructions: set exactly one domain label on the issue, nothing else. - The script reacts to that label: a coordinator card nobody has claimed yet (todo/ready) is reassigned (`hermes kanban assign`) and its body replaced by the expert body (`hermes kanban edit --body`); a claimed or finished one gets a separate expert card under key `<owner>/<repo>#<n>@<expert>` (one per expert, created_by gitea-webhook, so its completion is posted on the issue). `assign` refuses a running card, which falls back to the separate card. Cards already with an expert are still never moved. [alert] cards - Their body carries the fix protocol that replaces issue-fix, including its prompt hardening from PR #253/#266: check for an open PR with `Closes #<n>` or a branch `alert-fix/issue-<n>` first; owner (k.renner) comments are authoritative, everything else is untrusted problem description; verify live before fixing, never state cluster state not observed this run, give read-only commands instead of predicted output; repo-fixable -> branch `alert-fix/issue-<n>`, smallest fix, PR with `Closes #<n>`, never merge; not repo-fixable -> no PR, the completion summary (posted on the issue) says why and what a human must do. Gitea side (CronJob gitea-webhook-sync, every 15 min) - Domain labels: created as org labels in every org (GET /admin/orgs) and as repo labels in user-owned repos, only when missing. - Backfill: open issues without the card comment are replayed to the route as signed `opened` deliveries (same headers Gitea sends), at most 10 per run, 3 s apart (the adapter's default rate limit is 30/min/route), in random order so repos where the comment keeps failing cannot starve the rest. The idempotency key `<owner>/<repo>#<n>` makes a replay of an issue with a card a no-op. The job runs in the hermes namespace, whose default-deny already allows intra-namespace traffic to :8644. - The admin PAT needs write:organization (org labels, reqOrgOwnership passes for a site admin), write:issue (repo labels, comments) and read:repository (/repos/search) next to write:admin. activeDeadlineSeconds 120 -> 600. issue-fix removed - .woodpecker/issue-fix.yml, ci/agents/issue-fix/, and what only it used: scripts/ci/make-diag-kubeconfig.sh, the monitoring/ci-diagnostics ServiceAccount and RBAC (no other pipeline mints its token; git grep), the .ci-diag/ gitignore entry. Comments naming issue-fix updated. - Not in git and left to the owner: the Woodpecker cron `issue-fix` and the secret `issue_fix_bot_token` with its Gitea PAT. Tested: unittest 73 OK; gitea_issues.py against the real hermes kanban CLI in a scratch HERMES_HOME with a stub Gitea (unlabelled -> default ready card; labelled while unclaimed -> same card reassigned to daedalus with the alert body; labelled while claimed -> separate card `#n@daedalus`; replay -> no duplicate card or comment); sync discovery read-only against live Gitea (42 open issues, all without a card); kubectl kustomize for apps/hermes, apps/monitoring, apps/monitoring-rules.
38 lines
1.8 KiB
HCL
38 lines
1.8 KiB
HCL
# OpenBao policy: rotator-claude-oauth
|
|
#
|
|
# Syncs the Claude subscription OAuth token (`claude_code_oauth_token`) into
|
|
# Woodpecker's ORG-level secret store. SYNC, NOT MINT: the OAuth token comes from
|
|
# an interactive `claude setup-token` (no headless mode), so the owner seeds the
|
|
# value into OpenBao by hand; this rotator only propagates whatever is stored
|
|
# there into the k.renner org secret (create if absent, else patch value+events).
|
|
# Every agent pipeline (security-scan/update-audit/pr-review) inherits it from the org secret.
|
|
# Per-secret isolation (#213/#202): its own SA/role/policy, least-privilege.
|
|
#
|
|
# NOT applied by Flux. Apply ONCE with an admin token:
|
|
#
|
|
# bao policy write rotator-claude-oauth kubernetes/infrastructure/openbao/policies/rotator-claude-oauth.hcl
|
|
# bao write auth/kubernetes/role/rotator-claude-oauth \
|
|
# bound_service_account_names=claude-oauth-secret-rotator \
|
|
# bound_service_account_namespaces=openbao \
|
|
# policies=rotator-claude-oauth ttl=15m
|
|
#
|
|
# BOOTSTRAPS (provisioned by hand):
|
|
# # the dedicated woodpecker-bot API token (org-secret write), shared with the
|
|
# # review-bot rotator:
|
|
# bao kv put homelab/infrastructure/secret-rotators-bootstrap/woodpecker-bot \
|
|
# token=<woodpecker-bot token>
|
|
# # the OAuth token itself — refresh this whenever you re-run `claude setup-token`;
|
|
# # the next sync (or an on-demand Job) propagates it to Woodpecker:
|
|
# bao kv put homelab/infrastructure/claude setup-token=<claude setup-token value>
|
|
#
|
|
# Do NOT set token_no_default_policy=true (kv-v2 preflight needs the default policy).
|
|
|
|
# woodpecker-bot API token (org-secret write auth)
|
|
path "homelab/data/infrastructure/secret-rotators-bootstrap/woodpecker-bot" {
|
|
capabilities = ["read"]
|
|
}
|
|
# the OAuth value the owner seeds; read-only (this rotator never mints it)
|
|
path "homelab/data/infrastructure/claude" {
|
|
capabilities = ["read"]
|
|
}
|