280 280
recorded:        2026-06-12 (step.3000.A first impl run)
upstream:        nsidnev/fastapi-realworld-example-app
pinned_commit:   029eb7781c60d5f563ee8990a0cbfb79b244538c
postman:         vendored from source/upstream/postman/ (matches upstream's API spec at this commit)
APIURL:          http://127.0.0.1:8000/api
notes:           First number is asserted-OK count; second is asserted-total.
                 The .G TS bar is: result-OK count >= 280.
                 No known failures at this baseline.

reverified:      2026-08-10 — the same collection re-run against the
                 upstream Python service scored 280/280 with 0 failed
                 assertions and 31/31 requests. The numbers above are
                 CORRECT and reproducible; nothing here was stale.

resolved:        2026-08-10 — the TS side scored 293/293 for months,
                 THIRTEEN ASSERTIONS ABOVE this baseline, and the gap
                 was a behavioural difference reading as a better
                 score. GET /api/articles/feed returned every article
                 instead of the followed authors' — so the "Feed"
                 test took its non-empty branch and ran 14 shape
                 assertions where upstream runs one.

                 The single assertion that would have caught it is the
                 one that does not run when the feed is non-empty. A
                 `passed >= 280` bar cannot see a divergence that ADDS
                 passing assertions.

                 Fixed in runtime/src/articles_repo_impl.ts; both
                 sides now score 280/280 with an identical assertion
                 profile. Two checks guard it, because the collection
                 alone cannot:

                     tests/compare_to_upstream.sh   profile, not score
                     runtime/tests/feed_follow.sh   the populated-feed
                                                    case the collection
                                                    never exercises
