[kixelated]

Summary

This plans the follow-ups suggested by the decision inbox PR (#144):

• New quests in the kix epic, ranked right after the decision inbox:
  • [S] quest/m0/kix/reconcile.md: after each webhook, reconcile the project in the background with the installation token, so new items arrive ready to act on.
  • [S] quest/m0/kix/merge.md: a merge button on PR items, bound to the head SHA the maintainer saw. It reuses the merge-method selection from bot publication.
  • [S] quest/m0/kix/members.md: a maintainer joins a project's inbox once they pass its maintainer check, and drops out on any failed check.
• Folded into existing quests:
  • An unread count in the nav and on the app-icon badge, added to mobile.md.
  • A runner and account settings page, added to runner.md.

All three new quests require quest/m0/kix/prompts.md, and merge.md also requires quest/m0/kix/publication.md. #144 and #145 delete those files, so whichever PR merges second must update the Required links.

Planning decisions

Co-maintainers: how should a project reach a maintainer's inbox besides the one who enrolled it?

• ✅ Join on check (Recommended): a new [S] m0 quest. Membership only decides which projects are listed; it is not authority.
• List from GitHub on each inbox load
• Drop it

Merging from the inbox: where does the PR-item merge button live?

• ✅ New [S] quest (Recommended), which requires publication
• Fold into publication
• Fold into execution

Scale: new issues show as "Issue #N" until someone refreshes, and each inbox load makes about 5 GitHub calls per project. What do we plan?

• ✅ Reconcile only (Recommended): authority is still checked on every request, and the call count is left alone until it's a measured problem.
• Reconcile, plus an m1 quest for an authority cache
• Both in m0

Nav unread badge and runner settings page: new quests, or fold them into existing ones?

• ✅ Fold both (Recommended): the badge goes into mobile.md and the settings page into runner.md.
• Separate quests

Revocation: what happens to a member's membership when they later fail the maintainer check?

• ✅ Drop on failed check (Recommended), clearing their read and skip state
• Hide the project but keep the row

Rank: what priority do the three new quests get in the kix epic's Required list?

• ✅ Reconcile, then merge, then members, right after the decision inbox (Recommended)
• Members, then reconcile, then merge
• All three after publication

Checks

quest check, just check and just test pass.

🤖 Generated with Claude Code

(Written by Claude Opus 5.5)

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	⚠️ Failed 2026-10-19T05:55:58.958044Z	fee6f91	New commits
🔒 Security Review	✅ Completed 2026-10-19T05:54:34.371248Z	fee6f91	New commits

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: ca4a791ba2

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Preserve membership when authority cannot be checked

When GitHub is temporarily unavailable or rate-limits either API call in GitHubService.#maintainer, the check fails without proving that the user lost access. Treating any such failure as revocation would permanently delete the membership and its read/skip state, hide the project from the user's inbox, and require them to rediscover the project manually. Only an authoritative permission denial should remove membership; transient or indeterminate failures should fail the request without deleting state.

Useful? React with 👍 / 👎.

[kixelated]

Agreed. fee6f91 drops membership only when GitHub answers the check with a denial; an outage or rate limit fails the request and leaves membership and read/skip state alone. Added a rate-limited case to the tests.

(Written by Claude Opus 5.5)

[kixelated]

Merge summary:

• CI passed on fee6f91 (check, lifecycle on Ubuntu and macOS, native Windows x64 and arm).
• Codex review: one P1 on members.md, accepted. Membership now drops only when GitHub denies the maintainer check. An outage or rate limit fails the request and keeps membership. The planning decision (drop on a failed check) now explicitly covers denials only.
• Coordination: feat(worker): make the decision inbox the signed-in home #144 (deletes prompts.md) and feat(worker): publish agent work through the GitHub bot #145 (deletes publication.md) are still open, so this lands first. Main doesn't require branches to be up to date, so each of those PRs must merge main and drop its deleted file from the Required lists of reconcile.md, merge.md, and members.md, deleting a section that ends up empty. Otherwise quest check breaks on main.

(Written by Claude Opus 5.5)