Ayobami John Haastrup · Published 25 October 2026
Merged contributions contain a useful technical record: the failure that made a change necessary, the layer where the fix belongs, the regression that distinguishes old and new behaviour, and the review that improves it. This series makes that record readable beyond the pull request.
Start with the case studies#
| Read | Technical core | Accepted work |
|---|---|---|
| When the page leaves before the timer fires | Browser lifecycle, two buffering stages, immediate transport and duplicate prevention | PostHog #5322 |
| A subscription is a state machine | Delivery invalidation, re-entrancy, matching state, complete-snapshot refreshes and lifecycle ordering | PostHog #4794 |
| When an agent tool reports the wrong success | Requested action versus reported success, scope semantics, evidence grades and compiled defaults | Reticle #1739, #1745, #1747, #1749 |
These are original technical retrospectives, with links to pinned code, regression tests, review findings and CI. The contribution record credits maintainers' changes and original issue reports separately from my implementation. AI assistance is disclosed.
How to read the evidence#
A merged PR establishes acceptance into an upstream repository. A successful CI job establishes the outcome of that job on the recorded commit. A regression test's source shows what it asserts. A historical test count in a PR description is an author-reported result unless a corresponding execution record is inspected.
Those observations support different claims. The articles preserve the distinctions, including skipped jobs, incomplete local checks and later maintainer amendments. None of these articles claims a measured production improvement, independent reproduction, a new algorithm or academic peer review.
The evidence guide links the machine-readable records and their checksums. BibTeX citations are available for all three articles. The six PRs above received detailed source, review and CI analysis. The wider inventory below has individually verified merge metadata; its remaining entries have not yet received the same technical treatment.
Verified merged contribution inventory#
This is a dated selection of 21 merged PRs across six repositories, checked directly against GitHub PR metadata on 25 October 2026. It excludes my OneClickPostFactory organisation work and is not presented as an exhaustive lifetime contribution count. The JSON inventory records the exact merge and final-head commits, authorship and merge times.
| Repository / PR | Accepted contribution | Merged |
|---|---|---|
| PostHog/posthog-js #5322 | fix(browser): deliver final web vitals on page hide (#5318) | 2026-10-20 |
| reticlehq/reticle #1749 | fix(server): refuse ignored --drive on running daemon (#1692) | 2026-10-19 |
| reticlehq/reticle #1745 | fix(server): avoid presence advice for element state (#1686) | 2026-10-19 |
| reticlehq/reticle #1747 | fix(browser): handle blank and invalid snapshot scopes (#1679) | 2026-10-19 |
| reticlehq/reticle #1739 | fix(server): default console absence to error (#1674) | 2026-10-19 |
| PostHog/posthog-js #4794 | feat(surveys): add active matching surveys subscription | 2026-09-29 |
| element-hq/element-admin #599 | Fix scheduled room deletion timestamp display | 2026-09-15 |
| PostHog/posthog-js #4822 | feat(react-native): support shuffled survey questions and options | 2026-09-08 |
| StudentSuite/StudyMap #211 | fix(data): enforce canonical city slugs | 2026-09-06 |
| StudentSuite/StudyMap #192 | fix(map): handle missing MapTiler key | 2026-09-05 |
| StudentSuite/StudyMap #191 | fix(auth): show OAuth callback errors | 2026-09-05 |
| numbas/Numbas #1186 | Avoid duplicate score feedback | 2026-08-26 |
| PostHog/posthog-js #4604 | fix(react-native): support bare Hermes sourcemaps | 2026-08-24 |
| StudentSuite/StudyMap #189 | fix(map): validate suggest-place links and preserve input | 2026-08-24 |
| StudentSuite/StudyMap #187 | fix(pwa): harden service worker cache lifecycle | 2026-08-23 |
| StudentSuite/StudyMap #185 | ci: gate unit tests and add data freshness checks | 2026-08-22 |
| StudentSuite/StudyMap #186 | fix(auth): sanitize next redirects | 2026-08-22 |
| reticlehq/reticle #485 | test(bench): harden dirty-anchor regression harness | 2026-08-22 |
| reticlehq/reticle #474 | test(bench): pin dirty-anchor refusal in CI | 2026-08-22 |
| eddiejaoude/CodeReel #26 | feat: toggle playback from preview canvas | 2026-08-15 |
| eddiejaoude/CodeReel #16 | test: add Playwright end-to-end coverage | 2026-08-09 |
Developing this into research#
The strongest shared question is how software loses the meaning of an operation between requested intent, current state, execution and reported outcome. The articles offer concrete cases; they do not establish how common these defects are or how effective a particular review method is.
A possible empirical study would ask: does a review protocol built around lifecycle boundaries and stale observations detect defects that a baseline functional review misses? Before presenting that as a paper, the work needs:
- A defined sampling frame that includes unfixed or unsuccessful cases, rather than only selecting my accepted contributions.
- A literature review and precise categories, with independent assessment of whether cases fit them.
- Comparable before/after environments, explicit fault sequences and a baseline detection method.
- Recorded outcomes, false positives, detection cost and negative results, with replication material and clear ownership of each observation.
For the web-vitals case, an additional concrete study could compare browser-observed capture with server-observed receipt under controlled lifecycle transitions. The present unit and CI evidence does not measure that.
These are research directions. No new cross-project experiment, participant study or publication submission was performed to prepare this series.
Continuing the series#
The remaining contributions provide a review queue covering React Native survey ordering and sourcemaps, cache lifecycle, authentication feedback, timestamp interpretation, assessment feedback and end-to-end browser testing. Each candidate must earn a standalone article through its source, failure mechanism, review record and useful transferable lesson. A title or merge alone is not enough evidence for a technical conclusion.