Give the reachable rung both sides of the actionable boundary - #146
Merged
Conversation
Every ladder app sat at or below the review-grade tier, so nothing exercised the top of the ladder end to end — and the harness could not tell you that, because a rung named `reachable` existed and passed. The one app on it concatenates request input into its query, which the map correctly reports as `transformed-local`: proven, and precisely the tier a rule generator refuses to pin, since the transformation may be sanitising. So the rung now has two apps. `ladder/reachable-exact` passes a request parameter to an outbound request untransformed — the pinnable shape — and `ladder/reachable-transformed` keeps the concatenated one, which is not redundant: it is the only case pinning the boundary between "the map proved a flow" and "a consumer will act on it", which is where a false confirmation would come from. The old id `ladder/reachable` said neither of those things, and the pair names itself now. The tier is asserted here rather than only downstream. `expect.actionableFlow` distinguishes a proven flow from an actionable one (`exact-local` and rule-generatable), so if the exact app ever drifted to transformed, this fails — instead of a consumer's verdict assertion quietly starting to prove the weaker claim while still passing. The rung invariant relaxes from "all five exactly once" to every rung covered at least once with unique ids, plus a new assertion that BOTH sides of the actionable boundary are represented. That last one is what would have caught the original gap. Mutation-checked: concatenating the exact app, claiming the transformed app is actionable, and deleting the exact app each fail their own assertions and no others.
|
Tests now assert actionableFlow on both transformed and exact reachable cases. 🎯 Quality: 95% Elite · 📦 Size: Small 📈 This month: Your 81st PR — above team average · Averaging Excellent |
Contributor
Author
|
/review |
daniloradovic
approved these changes
Aug 19, 2026
devlob
approved these changes
Aug 19, 2026
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.
ENG-3622. Map side only — the platform fixtures and the
reachableverdict assertion follow oncesaas#1310 merges, generated by the emitter rather than hand-copied.
The gap
Every ladder app sat at or below the review-grade tier, so no app exercised the top of the ladder end to
end — and the harness could not tell you, because a rung named
reachableexisted and passed. The oneapp on it concatenates request input into its query:
The map reports that correctly as
transformed-local, which is exactly the tier a rule generator refusesto pin (the transformation may be sanitising). So a consumer keying on the actionable tier grades that app
one step below the top, and nothing in the harness said the top was untested.
What lands
Two apps on the rung, named for what they are:
ladder/reachable-exactaxios.get(req.body.target)— untransformedexact-local, rule-generatable, coordinatepost.targetladder/reachable-transformedtransformed-local, proven, not pinnableThe transformed one is not redundant: it is the only case pinning the boundary between "the map proved
a flow" and "a consumer will act on it", which is where a false confirmation would come from. The old id
ladder/reachablesaid neither thing, so the pair renames itself — which does break the platform'sreference to
reachable.jsonby design, and that follow-up regenerates it.axiosbecause the sink has to be one the map models. My first candidate (systeminformation, commandinjection) has no exec recognizer, so no flow could ever compile and the case would have asserted a
capability that does not exist. Its advisory is in the shared CVE fixture and unused by any other rung.
The tier is asserted here, not only downstream
expect.actionableFlowseparates a proven flow from an actionable one, so if the exact app ever drifts totransformed this fails here — rather than a platform verdict assertion quietly starting to prove the weaker
claim while still passing.
The rung invariant relaxes from "all five exactly once" to every rung covered at least once with unique
ids, plus a new assertion that both sides of the actionable boundary are represented. That last one is what
would have caught the original gap.
Verification
Full suite 1143 passed, 1 skipped (the emitter); typecheck clean. Mutation-checked: concatenating the exact
app, claiming the transformed app is actionable, and deleting the exact app each fail their own assertions
and no others.