What one pull request reaches, before anyone runs it.

Reviewers see changed files. featkpr follows them through the code to the routes and page parts behind a permission check, the scenarios behind those, and the tests to re-check. No model is asked: the trace is read from the code.

Ask for a private demo Area 4 of 5 · all five areas

featkpr's app on sample data · the trace shows BookStack pull request #6108 (shot 27 Sep 2026); the verdict page and the release flow come from the app's gallery (shot 28 Sep 2026)

Screens of featkpr's app run on sample data, so the numbers inside them are examples, not BookStack's. A screen marked "recorded from BookStack" replays featkpr's own records of BookStack's run of 26 Sep.

The trace, left to right #

The Request screen draws one pull request as a trace. Read it left to right: each changed file, what it guards, the scenarios behind that, and how many tests of the whole suite to re-check. The questions it raises for the owner go to Home (area 5).

The Request trace for pull request #6108: twelve changed files on the left wired to eight routes and page conditions, then rows of scenario pins with two amber rings, a meter reading 169 of 1,537.

Every pull request, one row #

The Requests screen lists each pull request featkpr has seen, with the same counts in a line: the tests to re-check as a meter, what it reaches, the owner's cards and whether a comment went up.

One row of the Requests screen: #6108, open, a re-check meter at 169 of 1,537, 12 routes, 5 screens and 20 scenarios, two cards, a comment mark.

The verdict on a real pull request #

The trace answers what a change reaches. The verdict answers whether it is safe to merge: which goals it touches, and whether each is proven on the change's own code.

needs a look · 2 goals touched · 0 proven · nothing ran

BookStack pull request #6213, “Hide image upload options in Image Manager when user lacks permission”, in a private mirror, 27 Sep 2026 The first verdict. Nothing ran: on 27 Sep featkpr did not yet run a pull request's own code.

0 broke · 19 held · 5 not proven

BookStack pull request #6213, run 36373649069, 28 Sep 2026, 02:58 EDT · not posted then: featkpr had no token to post with yet On 28 Sep 2026 the pull request's own code ran, isolated, beside BookStack's development tip. Held means the test passed before and after the change and failed as the wrong user. Of the 5 not proven, 4 have no test that runs at the base, and 1 passes even as the wrong user, so it proves nothing.

The merge-request verdict, posted with the change's own code run, on the plan for this week (the pull request's own code ran on BookStack #6213 on 28 Sep (0 broke, 19 held, 5 not proven); next, it posts on every push and fills the Goal sheets page). our plan of 28 Sep 2026 (roadmap)

What change impact gives a team

The verdict, and your answer to it #

The verdict is one comment on the pull request, edited in place as runs land. It is in one of five states: running, fail, decision needed, needs a look or pass, and it is never green when nothing ran. Its page has one sheet per goal the change touches: why it was touched, the base against the head, and where it flipped.

The verdict page for a pull request shaped like BookStack's #6213: a 'needs a look' header with 4 goals touched, 0 proven, 0 tests run; the changed files wired to routes and goals; a table of touched goals; and a Decisions rail listing intended, flaky and rerun. — On sample data shaped like #6213 as it stood on 27 Sep, before its own code ran, so the counts are examples. Five states; a decision needed is answered on the page or by replying: intended, flaky, rerun.

intended: the change meant to change this goal: its expected outcome is taken from the head, and its test is redrafted
flaky: the failure is not counted as broke; the goal needs a look
rerun: run it again

Answer on the page, or by replying to the comment, one word a line. What reviewers said, people, bots and agents alike, is kept beside the verdict as evidence.

How your app ships, and where featkpr acts on it #

featkpr reads how an app ships (branch names, tags and merge history) and proposes one of nine flows with its evidence. You fix the drawing and approve it. The approved drawing then shows what featkpr does on each arrow: a verdict comment on a pull request, one verdict for a whole release, status only where it stays quiet. It read BookStack as development → release by a pushed merge, then tags, and featkpr as dev → prod.

The release-flow editor's drawing of featkpr's own flow: feature branches into dev with a verdict comment, dev to prod with a promotion verdict, prod marked 'proven at', hotfix branches with a verdict and a back-merge watch, and status-only arrows for the back-merge and dependabot. — featkpr's own flow on a recorded world. The editor is live in the app since 28 Sep, under Settings → Release flow.

Next: Where a goal counts as proven: a stage and an environment per product, planned, from 12 Oct (the flow is live; next, each goal says where it was proven, e.g. 'proven · production-like at prod', never a plain 'proven'; Kargo later). our plan of 28 Sep 2026 (roadmap)

Trace a BookStack pull request with us #

A live walkthrough of the Request screen, and what it would take to trace your own pull requests.

Ask for a private demo