• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

Best possible solution:

Land this after maintainers accept the generic auth-hint contract or re-scope it to a WhatsApp-owned login surface while preserving backup-safe partial credential cleanup.

Do we have a high-confidence way to reproduce the issue?

Not applicable as a strict bug reproduction because this PR adds a new phone-code login capability. The PR body does provide structured real-device proof for the new flow, and source review covers the partial-credential cleanup path.

Is this the best way to solve the issue?

Unclear pending maintainer decision: the WhatsApp-local implementation follows Baileys' pairing-code contract and the prior backup-loss defect appears fixed, but making phoneNumber part of generic channel auth is a product/API choice.

Label changes:

• add proof: sufficient: Contributor real behavior proof is sufficient. The PR body includes structured after-fix proof from a local checkout paired with a physical Android WhatsApp device, including redacted runtime logs and final linked/healthy status.
• add rating: 🐚 platinum hermit: Current PR rating is 🐚 platinum hermit because proof is 🦞 diamond lobster, patch quality is 🐚 platinum hermit, and Strong real-device proof and a focused patch, with remaining merge risk centered on API direction and session-state sensitivity rather than a confirmed code defect.
• add status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (logs): The PR body includes structured after-fix proof from a local checkout paired with a physical Android WhatsApp device, including redacted runtime logs and final linked/healthy status.
• remove rating: 🧂 unranked krab: Current PR rating is rating: 🐚 platinum hermit, so this older rating label is no longer current.
• remove status: ⏳ waiting on author: Current PR status label is status: 👀 ready for maintainer look.

Label justifications:

• P2: This is a normal-priority user-facing WhatsApp login improvement with focused blast radius but auth/session sensitivity.
• merge-risk: 🚨 compatibility: Adding phoneNumber to ChannelAuthAdapter expands a generic plugin-facing auth contract.
• merge-risk: 🚨 auth-provider: The PR changes WhatsApp login and credential pairing behavior through Baileys.
• merge-risk: 🚨 session-state: The PR changes how partial WhatsApp credentials are detected, cleared, and restored from backup.
• rating: 🐚 platinum hermit: Current PR rating is 🐚 platinum hermit because proof is 🦞 diamond lobster, patch quality is 🐚 platinum hermit, and Strong real-device proof and a focused patch, with remaining merge risk centered on API direction and session-state sensitivity rather than a confirmed code defect.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (logs): The PR body includes structured after-fix proof from a local checkout paired with a physical Android WhatsApp device, including redacted runtime logs and final linked/healthy status.
• proof: sufficient: Contributor real behavior proof is sufficient. The PR body includes structured after-fix proof from a local checkout paired with a physical Android WhatsApp device, including redacted runtime logs and final linked/healthy status.

What I checked:

• Current main behavior: Current main's channels login command exposes --channel, --account, and --verbose, but no phone-code or phone-number login option. (src/cli/channels-cli.ts:255, c14a0c6d63f7)
• PR CLI surface: The PR merge result adds --phone-number <number> and passes it into runChannelLogin. (src/cli/channels-cli.ts:259, 23d55699dff2)
• WhatsApp phone-code implementation: The PR normalizes the phone number, clears stale partial phone-code auth, creates a Baileys socket with a macOS Chrome browser profile, waits for pairing readiness, then calls requestPairingCode. (extensions/whatsapp/src/login.ts:174, 23d55699dff2)
• Backup-safe cleanup coverage: The PR tests partial phone-code credentials as not linked, clears owned partial auth, and restores a valid creds.json.bak instead of deleting it. (extensions/whatsapp/src/auth-store.test.ts:240, 23d55699dff2)
• Plugin API expansion: The PR adds phoneNumber?: string | null to the generic ChannelAuthAdapter, which is a compatibility-sensitive plugin contract choice. (src/channels/plugins/types.adapters.ts:361, 23d55699dff2)
• Dependency contract check: Baileys 7.0.0-rc13 requestPairingCode sets creds.pairingCode, fills creds.me from the phone number, emits creds.update, and then sends the WhatsApp link-code registration node. (baileys@7.0.0-rc13/lib/Socket/socket.js:593)

Likely related people:

• steipete: Current-main blame and follow-history for the WhatsApp login/auth/session files and the channel auth adapter point to Peter Steinberger's commit 8df01a8683de6065691b62afcdbc8bfc69e6a20d. (role: recent area contributor; confidence: medium; commits: 8df01a8683de; files: extensions/whatsapp/src/login.ts, extensions/whatsapp/src/auth-store.ts, extensions/whatsapp/src/session.ts)

Codex review notes: model gpt-5.5, reasoning high; reviewed against c14a0c6d63f7.

• Eggs appear after the PR passes real-behavior proof. It is here for vibes, not verdicts: it does not change labels, ratings, merge decisions, or automation.
• The shell reacts to review momentum: open follow-up work warms it up, re-review makes it wobble, and a clean final review lets it hatch.
• Hatchability usually comes from sufficient real-behavior proof, no blocking P0/P1/P2 findings, no security attention needed, and clean correctness. A merged PR is already final, so merge makes the egg hatchable independently.
• The hatch is seeded from this repository and PR number, so the same PR keeps the same creature; the reviewed head SHA can only change safe visual details.
• Rarity is just collectible sparkle: 🥚 common, 🌱 uncommon, 💎 rare, ✨ glimmer, and 🌈 legendary.