First item: later, for environments where the CI server has repo-admin, consider an opt-in (off-by-default) feature to auto-register + idempotently reconcile the issue_comment webhook — preserving the read-only/polling default. Parked, out of current scope. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
1.5 KiB
1.5 KiB
Deferred ideas / future enhancements (orchestrator-tracked)
Post-DONE or "revisit later" ideas that are intentionally out of scope for the current build
(§2 Definition of Done). Not active work — parked here so they aren't lost. The loops may pull an
item into the project BACKLOG.md as [idea] if/when it becomes relevant.
- Optional webhook self-registration (admin-access environments).
We deliberately made polling the primary trigger and require the CI server/bot to run on
read-level access only — so the server does not auto-register Gitea webhooks (that needs
repo-admin), and webhook setup is a documented manual admin task (§4.1,
docs/enroll-recipe.md). Later, for environments where the CI server does hold admin on the recipe repos (or an org-level admin token is available), consider adding an opt-in, off-by-default feature (e.g.WEBHOOK_AUTOREGISTER=1) that auto-registers and idempotently reconciles theissue_commentwebhook (URL, events, HMAC secret) on enrolled repos — matching our declarative-reconcile pattern (§9) — giving low-latency push triggering with zero manual setup. Must stay off by default and fall back to manual-doc + polling when admin isn't available, so the least-privilege (read-only) default is preserved. Why deferred: polling already satisfies D1 and the read-only posture is the goal; this is a convenience optimization for a different deployment profile. Added: 2026-05-27.