Skip to content

fix(config): watch this fork, not only upstream - #72

Open
Svector-anu wants to merge 1 commit into
mainfrom
fix/watch-own-fork
Open

fix(config): watch this fork, not only upstream#72
Svector-anu wants to merge 1 commit into
mainfrom
fix/watch-own-fork

Conversation

@Svector-anu

Copy link
Copy Markdown
Owner

what

memory/watched-repos.md still held the untouched upstream default — just aeonfun/aeon. git log on that file shows only inherited upstream commits, none fork-specific. So every skill resolving an empty var through it was pointed at upstream, not this fork.

what that broke

  • auto-merge is a no-op that reports healthy. It logs Repo(s): aeonfun/aeon and AUTO_MERGE_SKIP: 0/0 qualifying every run. 20 runs, 19 successes, 95% success rate, quality score 3 — and it has merged nothing, ever.
  • pr-review with an empty var reviewed upstream's queue instead of ours.
  • feature's default watched selector resolved to upstream — which is why aeon.yml keeps it dispatch-only with the note that a bare dispatch "would auto-PR upstream." That caveat is a symptom of this, not an independent design choice.

the change

One line: add the fork alongside upstream rather than replacing it, so nothing that currently happens stops happening.

blast radius — verified before changing, not assumed

Revert this commit to restore the previous targeting.

memory/watched-repos.md still held the untouched upstream default of
just aeonfun/aeon — git log on the file shows only inherited upstream
commits, none fork-specific. every skill that resolves an empty var
through it was therefore pointed at upstream rather than this fork:

- auto-merge logged "Repo(s): aeonfun/aeon" and "0/0 qualifying" on
  every run. 20 runs, 19 successes, 95% success rate, quality score 3,
  and it has merged nothing, ever. a daily no-op reporting healthy.
- pr-review with an empty var reviewed upstream's queue instead of ours.
- feature's default `watched` selector resolved to upstream, which is
  why aeon.yml keeps it dispatch-only with a note that a bare dispatch
  "would auto-PR upstream" — a symptom of this, not a separate choice.

add the fork alongside upstream rather than replacing it, so nothing
that currently happens stops happening.

immediate blast radius is small and was verified before making the
change: auto-merge requires a bot author AND green checks, and the only
bot-authored PRs here (#3, #4, #5, #20, #22) are all mergeable=false /
dirty, so they are skipped as blocked. no new bot PRs are being created
either — skills now commit straight to main rather than opening PRs, so
the old PR-per-run pattern that produced those five is gone. feature is
workflow_dispatch-only and does not act on its own. the real behavioural
change is pr-review reviewing this fork's own queue, which posts comments.

revert this commit to restore the previous targeting.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant