Repository navigation
Conversation
|
@codex review Please perform a fresh, independent, adversarial review of this entire PR at HEAD |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
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[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 8fdfef97cd
ℹ️ 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".
| if (!whollyInside && | ||
| !(checkpoint.sendAcknowledged === true && overlapsAttempt)) continue; |
There was a problem hiding this comment.
For a normal acknowledged POST lasting from, for example, 20:25:29.220 to 20:25:29.403, this condition accepts a created_at bucket covering 20:25:29.000–29.999, even though part of that bucket predates the attempt. A positive HTTP response proves that some POST succeeded but does not prove that the sole matching record returned by a stale, filtered, or paginated GET is that POST rather than an identical own-user announcement created after the cursor and before startedAt; confirming it can therefore enable entries and eventual real-BON settlement against the wrong opening. Keep requiring the entire bucket to fall within the checkpoint window rather than treating overlap plus acknowledgement as sufficient.
AGENTS.md reference: AGENTS.md:L54-L60
Useful? React with 👍 / 👎.
|
@codex review Fresh full PR review at latest HEAD |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 1174906361
ℹ️ 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".
| if (!whollyInside && | ||
| !(hasUniqueProof && overlapsAttempt && | ||
| canonical(message?.message, true).endsWith(proof))) continue; |
There was a problem hiding this comment.
The fresh evidence at latest HEAD is the new hasUniqueProof && overlapsAttempt exception, which still confirms a message whose server timestamp bucket is not wholly contained in the POST window. For a send beginning at 20:25:29.220 with created_at=20:25:29, this accepts the 20:25:29.000–29.999 bucket even though its lower bound predates the attempt; the marker identifies the message but does not change the recorded timestamp resolution, while the repository invariant explicitly forbids confirmation from mere same-second overlap. This can enable entries and eventual BON settlement without the required publication-time proof.
AGENTS.md reference: AGENTS.md:L54-L60
Useful? React with 👍 / 👎.
| content = content.replace( | ||
| /\[(?:\/)?(?:b|i|u|s|color(?:=[^\]]*)?|size(?:=[^\]]*)?|url(?:=[^\]]*)?)\]/gi, | ||
| "" |
There was a problem hiding this comment.
When the optional custom message contains a supported tag outside this short allowlist—for example [quote]Good luck[/quote]—the prepared-side canonical form retains the BBCode while DarkPeers renders it as HTML and the rendered-side branch removes the resulting tags. The already-posted opening therefore never matches authoritative history, leaving its checkpoint pending and blocking entries, recovery, and subsequent starts even though the exact proof marker survived. Either parse BBCode consistently with DarkPeers or reject unsupported markup before the public POST.
AGENTS.md reference: AGENTS.md:L66-L67
Useful? React with 👍 / 👎.
|
@codex review Fresh adversarial review of ENTIRE PR at current HEAD |
|
@codex review Please conduct a fresh, security-focused full-PR review at HEAD |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d70f2e8f38
ℹ️ 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".
| const url = new URL("/api/chat/messages/" + DARKPEERS_MAIN_CHATROOM_ID, location.origin); | ||
| url.searchParams.set("after_id", String(afterId)); | ||
| const response = await fetchWithTimeout( | ||
| url, { credentials: "include", cache: "no-store" }, 5000 |
There was a problem hiding this comment.
When a confirmed giveaway is restored after enough Main Chat traffic, the original opening can fall outside the endpoint's current result page—especially because the opening path itself notes that UNIT3D may ignore after_id. This verifier retries the same unpaginated URL three times, so the required saved messageId is never found even though it remains in older authoritative history; restore then permanently pauses entries and real-BON settlement. Follow the API's pagination until the saved ID or bounded publication range is exhausted.
AGENTS.md reference: AGENTS.md:L128-L132
Useful? React with 👍 / 👎.
|
@codex review Please run a fresh, comprehensive and adversarial review of the ENTIRE PR at HEAD |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 98db4dd231
ℹ️ 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".
| if (!whollyInside && | ||
| !(hasUniqueProof && overlapsAttempt && | ||
| canonical(message?.message, true).endsWith(proof))) continue; |
There was a problem hiding this comment.
When the authenticated host's marked payload appears once in the accepted timestamp overlap and a second time after windowEnd—for example, because a delayed duplicate is created after sendCompletedAt—the later record is discarded here before entering matches, leaving matches.length === 1 and confirming an ambiguous opening. Count matching author/text/proof occurrences before applying the publication-window test and reject confirmation whenever the marker occurs more than once.
AGENTS.md reference: AGENTS.md:L61-L67
Useful? React with 👍 / 👎.
…epting distinct opening duplicates
|
@codex review Please perform a fresh independent adversarial FULL-PR review of latest HEAD |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d188d45c3a
ℹ️ 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".
| if (!expectedHost || serverName !== expectedHost) continue; | ||
| } | ||
| if (canonical(message?.message, true) !== expected) continue; | ||
| matchingAnnouncementIds.add(id); |
There was a problem hiding this comment.
Fresh evidence at latest HEAD is that confirmed restores still discard every non-saved ID at lines 114–115 before adding candidates to matchingAnnouncementIds. If the returned payload contains the original confirmed message plus a copied announcement with the same author, rendered text, and proof under another ID—even outside the POST window—the copy is never counted and the original is accepted, allowing entries and eventual real-BON settlement despite an ambiguous duplicated marker. Perform the author/text/proof duplicate scan across all post-cursor IDs before restricting the actual confirmation candidate to checkpoint.messageId.
AGENTS.md reference: AGENTS.md:L58-L67
Useful? React with 👍 / 👎.
| pageIds.length >= 100 && pageIds.every(id => | ||
| Number.isSafeInteger(id) && id > 0 | ||
| ) && Math.min(...pageIds) > confirmedId) { |
There was a problem hiding this comment.
This treats array length as proof of a full 100-message page without checking ID uniqueness. For example, a response containing 99 newer messages plus a replayed row has pageIds.length === 100 and a minimum ID above the saved opening, so it takes historyEvicted and resumes settlement even though the response is only a 99-message short history; repeated API rows are explicitly considered possible elsewhere in this verifier. Base the rollover exception on at least 100 distinct valid message IDs so only a genuinely full latest page can bypass direct re-verification.
AGENTS.md reference: AGENTS.md:L75-L82
Useful? React with 👍 / 👎.
1 participant
Regressão real
O PR #29 introduziu uma confirmação do anúncio de abertura que compara o BBCode enviado com o HTML/JoyPixels devolvido por
GET /api/chat/messages/1, e exige timestamps inteiramente contidos numa janela de POST de apenas 183 ms quando o servidor regista segundos inteiros. Em produção, o anúncio chega ao Main Chat mas o userscript fica preso numpendinge mostra alertas a cada carregamento.Correção
sendAcknowledgedno checkpoint antes de verificar o anúncio.sponsorStartTsconserva o limite conservador: final do bucket do timestamp do servidor.created_atcom precisão ao segundo, anúncio anterior, colisões, autor errado, texto diferente e ausência de confirmação HTTP.Segurança operacional
Não usar esta atualização para concluir automaticamente sorteios antigos ainda
pending. O sorteio de 2026-10-14 deve ser cancelado explicitamente no browser, com cópia de segurança do snapshot, anúncio público de cancelamento e conferência separada de eventuais ofertas BON.Validação
Aguardar Validate BONanza CI e revisão independente antes de merge/publicação. Fontes em
src/; bundle gerado mantido sincronizado.