Repository navigation
Add proactive status bar to web UI - #23
Merged
Merged
Conversation
Polls /tasks/active every 5s, shows "Working on: ..." when tasks are in progress. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2 of 4 tasks
This was referenced Apr 21, 2026
liususan091219
pushed a commit
to liususan091219/sutando-fork
that referenced
this pull request
May 28, 2026
Polls /tasks/active every 5s, shows "Working on: ..." when tasks are in progress. Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
sonichi
added a commit
that referenced
this pull request
Aug 3, 2026
…shared login
`is_mine` was `author == owner_login`. Several agents commit through the SAME
GitHub account, so that boolean was True for every one of them and for the human
whose account it is -- three principals collapsed into one field whose name says
"mine". A consumer reading it as "the owner\x27s PR" and a consumer reading it as
"my PR" are both wrong, and nothing in the record could correct either.
That is not hypothetical: it produced a digest that handed the owner 13 PRs as
"your own 13" when he had authored none of them, and told him he was the author
of a PR another agent wrote.
The `Stand:` commit trailer is the only signal that separates the agents, so
derive identity from it:
stands distinct Stand trailers across the PR\x27s commits, sorted
principal the stand, or "joint" (>1), or "unattributed" (none)
is_mine now trailer-derived via --stand; null when --stand is omitted,
because unknown beats a confident guess
`state_hash` keys on `principal` instead of `is_mine`: a change of author now
refires the digest. This rehashes once on first run after merge.
Trailers are fetched in their own narrow GraphQL pass, NOT by adding `commits`
to `gh pr list --json`: that also pulls each commit\x27s `authors` connection and
at --limit 1000 GitHub rejects the entire query ("up to 1,000,000 possible nodes
which exceeds the maximum limit of 500,000"), returning ZERO PRs rather than a
partial answer.
Falsified against the old code -- three PRs, one shared login, three different
principals, and the old field cannot tell them apart:
PR | OLD is_mine | NEW principal | NEW is_mine (as Pro)
#20 | True | Echo Act IV Pro | True
#21 | True | Echo Act IV Mini | False
#23 | True | unattributed | False
Verified on live data: the tool reproduces by machine the partition that had to
be derived by hand -- 7 Pro / 1 Mini / 4 joint across the 12 open shared-login
PRs.
Stand: Echo Act IV Pro
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
sonichi
added a commit
that referenced
this pull request
Aug 3, 2026
…shared login
`is_mine` was `author == owner_login`. Several agents commit through the SAME
GitHub account, so that boolean was True for every one of them and for the human
whose account it is -- three principals collapsed into one field whose name says
"mine". A consumer reading it as "the owner\x27s PR" and a consumer reading it as
"my PR" are both wrong, and nothing in the record could correct either.
That is not hypothetical: it produced a digest that handed the owner 13 PRs as
"your own 13" when he had authored none of them, and told him he was the author
of a PR another agent wrote.
The `Stand:` commit trailer is the only signal that separates the agents, so
derive identity from it:
stands distinct Stand trailers across the PR\x27s commits, sorted
principal the stand, or "joint" (>1), or "unattributed" (none)
is_mine now trailer-derived via --stand; null when --stand is omitted,
because unknown beats a confident guess
`state_hash` keys on `principal` instead of `is_mine`: a change of author now
refires the digest. This rehashes once on first run after merge.
Trailers are fetched in their own narrow GraphQL pass, NOT by adding `commits`
to `gh pr list --json`: that also pulls each commit\x27s `authors` connection and
at --limit 1000 GitHub rejects the entire query ("up to 1,000,000 possible nodes
which exceeds the maximum limit of 500,000"), returning ZERO PRs rather than a
partial answer.
Falsified against the old code -- three PRs, one shared login, three different
principals, and the old field cannot tell them apart:
PR | OLD is_mine | NEW principal | NEW is_mine (as Pro)
#20 | True | Echo Act IV Pro | True
#21 | True | Echo Act IV Mini | False
#23 | True | unattributed | False
Verified on live data: the tool reproduces by machine the partition that had to
be derived by hand -- 7 Pro / 1 Mini / 4 joint across the 12 open shared-login
PRs.
Stand: Echo Act IV Pro
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
john-the-dev
added a commit
that referenced
this pull request
Aug 3, 2026
…shared login (#2553) * fix(pr-flag): identify the authoring AGENT by Stand trailer, not the shared login `is_mine` was `author == owner_login`. Several agents commit through the SAME GitHub account, so that boolean was True for every one of them and for the human whose account it is -- three principals collapsed into one field whose name says "mine". A consumer reading it as "the owner\x27s PR" and a consumer reading it as "my PR" are both wrong, and nothing in the record could correct either. That is not hypothetical: it produced a digest that handed the owner 13 PRs as "your own 13" when he had authored none of them, and told him he was the author of a PR another agent wrote. The `Stand:` commit trailer is the only signal that separates the agents, so derive identity from it: stands distinct Stand trailers across the PR\x27s commits, sorted principal the stand, or "joint" (>1), or "unattributed" (none) is_mine now trailer-derived via --stand; null when --stand is omitted, because unknown beats a confident guess `state_hash` keys on `principal` instead of `is_mine`: a change of author now refires the digest. This rehashes once on first run after merge. Trailers are fetched in their own narrow GraphQL pass, NOT by adding `commits` to `gh pr list --json`: that also pulls each commit\x27s `authors` connection and at --limit 1000 GitHub rejects the entire query ("up to 1,000,000 possible nodes which exceeds the maximum limit of 500,000"), returning ZERO PRs rather than a partial answer. Falsified against the old code -- three PRs, one shared login, three different principals, and the old field cannot tell them apart: PR | OLD is_mine | NEW principal | NEW is_mine (as Pro) #20 | True | Echo Act IV Pro | True #21 | True | Echo Act IV Mini | False #23 | True | unattributed | False Verified on live data: the tool reproduces by machine the partition that had to be derived by hand -- 7 Pro / 1 Mini / 4 joint across the 12 open shared-login PRs. Stand: Echo Act IV Pro Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(pr-flag): a failed trailer fetch is UNKNOWN, not a confident identity qingyun-wu's review is right, and the defect is the same shape this PR exists to remove. `_attach_commits` turned both failure paths -- a non-zero `gh api graphql` and an unexpected response -- into `pr["commits"] = []`, which downstream is indistinguishable from a successful fetch that found no trailer. So a transient error, rate limit or permissions hiccup produced: principal = "unattributed" is_mine = False for a PR this agent actually authored. That is a confident wrong identity, which is exactly what `is_mine = author == owner_login` was doing before this PR. My own body says "unknown beats a confident guess" while the fetch path did the opposite. A `STANDS_UNAVAILABLE` sentinel now marks the could-not-look case, and it is kept distinct from looked-and-found-none: could not look -> principal "unknown" is_mine None looked, none -> principal "unattributed" is_mine False looked, found -> principal "<stand>" is_mine per --stand `is_mine` is None for the unknown case even when --stand is supplied, so an outage can never relabel this agent's own PRs as someone else's. Behavioural falsification against the previous head, same input (a PR by this agent whose fetch failed): OLD principal=unattributed is_mine=False <- confident, and wrong NEW principal=unknown is_mine=None <- honest Three regressions added, including one asserting the dedup hash MOVES between "unknown" and a real stand -- otherwise a fetch outage would silently inherit the previous run's identity verdict instead of refiring. ruff clean; full pr-flag suite passes. Stand: Echo Act IV Pro Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(pr-flag): a 100-commit page was treated as the whole history qingyun-wu and john-the-dev both blocked on the same thing at head 32a5ce7, and they are right: `_attach_commits()` queried `commits(first:100)` with no `pageInfo`/cursor and treated that first page as complete. The STANDS_UNAVAILABLE sentinel added earlier covers a FAILED fetch but not a SUCCESSFUL, truncated one. That is the same defect this PR exists to remove, one layer down: a confident wrong identity. Demonstrated against the parent using the suite's own fixture -- TRUNCATED at 100 (what the parent fetches) principal='unattributed' is_mine=False COMPLETE 101 (the truth) principal='Echo Act IV Pro' is_mine=True so a Stand trailer on commit 101 silently disowns the agent's own PR, exactly as john's activated repro showed. The query now paginates with `pageInfo{hasNextPage endCursor}` and an `$after` cursor, walked to exhaustion. Anything that prevents a COMPLETE walk -- a failed page, `hasNextPage` with no cursor, or the defensive 100-page ceiling -- fails CLOSED to STANDS_UNAVAILABLE rather than publishing a partial set. A truncated history is not a small error here: one missing commit can drop the only trailer. `_gh_stands_page()` is a seam so the walk is testable without a network, which is what lets the regression exercise `_attach_commits()` itself rather than only `raw_state()` fixtures (john's explicit ask). Its `# pragma: no cover` moved down to the subprocess boundary; `_attach_commits` is now covered. Three regressions, inserted ABOVE the suite's final print so a failure cannot report after a green verdict: trailer-on-commit-101 survives pagination (and the cursor is actually threaded), a mid-walk page failure fails closed, and hasNextPage-without-a-cursor fails closed. ruff clean; py_compile clean; src-map parity unchanged; full suite ALL PASS. Stand: Echo Act IV Pro Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com> Co-authored-by: Rui Wang <52230987+john-the-dev@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Shows current autonomous work in the web client.