docs(settings): record the social preview as applied and verified (GTM-43) - #37
Merged
Conversation
…M-43) The card was uploaded on 2026-08-13. This replaces the intended-but-unset note, which was the last thing standing between GTM-43 and its acceptance criteria. Verified by fetching the rendered og:image, not by trusting the dashboard. The host is the discriminator — GitHub serves generated cards from opengraph.githubassets.com and uploaded ones from repository-images.githubusercontent.com, and it now reads the latter. The width/height pair that accompanied the generated card is gone, as GitHub omits dimensions for uploads. The served bytes were then compared against assets/social-card.png and are byte-identical: 127,369 bytes, SHA-256 89213ee0..., PNG 1200x630 RGBA. GitHub did not re-encode on upload, so the card users see is the card in the repository. Also observed rendering in a real Open Graph client — full card, no cropping, footer legible — so this is not only a correct meta tag. The re-check command is recorded inline, because there is no REST API for this setting and therefore no test that can watch it. If the host ever reads opengraph.githubassets.com again, the setting has been lost.
Reviewer's GuideUpdates the repository settings documentation to record that the social preview image has been uploaded, verified via Open Graph metadata and byte comparison, and provides a repeatable manual verification command since GitHub exposes no API for this setting. Sequence diagram for manual social preview verificationsequenceDiagram
actor Maintainer
participant Shell
participant GitHub
Maintainer->>Shell: curl -sL https://github.com/workspacejson/standard | grep 'og:image"'
Shell->>GitHub: HTTP GET /
GitHub-->>Shell: HTML with og:image metadata
Shell-->>Maintainer: og:image line
alt [og:image host is repository-images.githubusercontent.com]
Maintainer->>Maintainer: Confirm social preview applied and serving assets/social-card.png
else [og:image host is opengraph.githubassets.com]
Maintainer->>Maintainer: Detect social preview setting lost (default generated card)
end
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
There was a problem hiding this comment.
qmarcelle has reached the 50-credit limit for trial accounts. To continue receiving code reviews, upgrade your plan.
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey - I've left some high level feedback:
- The verification block in
docs/repository-settings.mdis quite dense; consider tightening the prose (e.g., moving the byte/sha details into a short bullet list or parenthetical) to keep the main narrative easy to scan. - The
curlre-check command relies on a simplegrep 'og:image"'; you might want to make the suggested check more robust (for example, grepping specifically for the expectedrepository-images.githubusercontent.comhost) so that readers know exactly what success vs. failure looks like from the command output.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- The verification block in `docs/repository-settings.md` is quite dense; consider tightening the prose (e.g., moving the byte/sha details into a short bullet list or parenthetical) to keep the main narrative easy to scan.
- The `curl` re-check command relies on a simple `grep 'og:image"'`; you might want to make the suggested check more robust (for example, grepping specifically for the expected `repository-images.githubusercontent.com` host) so that readers know exactly what success vs. failure looks like from the command output.Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
…ourcery) The command printed the og:image tag for a human to read. The failure mode this setting has is a *different host serving a plausible-looking card*, and an eyeballed tag looks fine either way — which is exactly how the unset state survived until GTM-43 went looking. It now greps for the uploaded-card host and prints OK or LOST. Verified in both directions: against the live page it reports OK, and against a simulated opengraph.githubassets.com tag it reports LOST. Sourcery also suggested tightening the verification prose. Kept as is — the byte count and SHA-256 are the evidence the served card is the repository's card, and moving them into a parenthetical would make the one falsifiable claim in the section the easiest part to skip.
There was a problem hiding this comment.
qmarcelle has reached the 50-credit limit for trial accounts. To continue receiving code reviews, upgrade your plan.
|
qmarcelle
added a commit
that referenced
this pull request
Aug 13, 2026
… (GTM-33) (#38) * docs: correct the review-gate claims to what the API actually returns (GTM-33) Both surfaces claimed governance controls this repository does not have. `docs/repository-settings.md` stated emphatically that code-owner review "is enabled and does bind" and that "nothing here should be read as saying that control is inert — it is not." The API returns `require_code_owner_reviews: false`. The document's own rule is that the API is the arbiter, so this is the rule being exercised against the document that carries it. README repeated the same claim. The remediation section described a two-phase plan with "Phase 1 (current): Greptile as independent review gate". Both phases have in fact executed, and the result is worse than either intended: - Phase 2 already happened — required code-owner approval is off. - Phase 1 was tried and withdrawn. `Greptile Review` was required from 2026-08-12 and removed 2026-08-13, because the Greptile trial account hit its 50-credit limit and now posts a credit-limit notice instead of a review while emitting no check run. Observed on PR #37: reviewed head 4f9e8f6, zero check runs, where #34/#35/#36 each produced exactly one. A required context nothing can emit blocks every merge. So the honest statement is stronger than the one being replaced. It was "no enforceable *independent* review path"; it is now "no review requirement at all" — no approving-review count, no code-owner requirement, and no required review status context. CI correctness and conversation resolution are the whole merge contract, and admin enforcement is off on top of that. A quota notice is not review evidence. Absence of a check is recorded as absence, never as a pass. * docs(settings): insert the missing relative pronoun (Sourcery) "A required context nothing can produce" reads as if a word is dropped. "A required context that nothing can produce" is what was meant. * docs(settings): make the document agree with itself (GTM-33) Correcting the code-owner and Greptile claims left six places contradicting the corrections — a document arguing that settings drift is detectable only if the intent is written down should not itself say two things. - Heading and framing still said "no enforceable independent-review path"; the measured state is no review requirement at all. - Point 3 explained why a self-authored change "cannot satisfy the code-owner requirement" two paragraphs after point 2 established there is no such requirement. It now states what it is actually evidence for: re-enabling that control would block every change rather than get any reviewed. - The closing paragraph still described the Greptile/Sourcery transition as planned, immediately above the section recording that it was tried and withdrawn. - The interim-governance diagram still listed "Required Greptile review" as a merge authorization input. - "The remediation has two phases:" ran directly into "Both phases have been executed." - The table listing controls "not in place" gained two rows while its lead-in still said two. Also sharpened one thing the corrections understated: with no required reviewer, `enforce_admins: false` is no longer the first way an unreviewed change reaches `main` — it is the second.
qmarcelle
added a commit
that referenced
this pull request
Aug 17, 2026
… exhausted (#43) The protocol document still named Greptile the required automated status gate and told agents not to merge while its review was pending. That requirement cannot be satisfied and would block every merge indefinitely. It also recorded the wrong cause. It said the app was 'likely not installed'; the app IS installed and does respond, with a 50-credit trial-limit notice and zero check runs. Observed on PR #37 on 2026-08-13, and again on PR #42, which carries the notice twice. An uninstalled app is a setup gap; an exhausted quota is a reviewer that answers and says nothing. A quota notice is never a pass. Three claims corrected against measured state: * Greptile as required status check -> withdrawn 2026-08-13, verified against branch protection, which requires exactly test (20), test (22) and Four-path producer conformance * 'Require code owner review: currently required' -> disabled; require_code_owner_reviews is false * the Greptile-premised remediation sequence -> both of its first two steps have already executed, and the outcome is that no reviewer requirement remains at all docs/repository-settings.md already recorded all of this accurately on 2026-08-13. This document had drifted away from its own sibling, which is the defect: two files in one repository disagreeing about whether a merge gate exists. The .greptile/ rules are kept. They are correct and cost nothing while dormant, and credits are the only thing standing between them and running again.
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.
Closes GTM-43. Clears the last §4 machine-hygiene gate on GTM-33.
The card was uploaded to Settings → General → Social preview on 2026-08-13. This replaces the intended-but-unset note in
docs/repository-settings.md, which was acceptance step 3.Verified by observation, not by the dashboard
og:imagehostopengraph.githubassets.com— generatedrepository-images.githubusercontent.com— uploadedog:image:width/:height1200/600The host is the discriminator — a generated card and an uploaded one are served from different hosts, so the two cannot be confused.
The served bytes are the repository's bytes
GitHub did not re-encode on upload, so what unfurls is exactly
assets/social-card.png.Also observed rendering in a real Open Graph client (iMessage unfurl) — full card, no cropping, footer legible. No rendering defect, so no new card was generated.
Why the re-check command is in the file
GitHub exposes no REST API for the social preview, so no CI test can watch this setting. The document records the one-line
curlthat re-verifies it and states the failure signature, since prose is the only available evidence.This changes
docs/repository-settings.mdonly.README.mdis untouched, so the GTM-33 §5 comprehension revision is unaffected.Summary by Sourcery
Documentation: