Skip to content

Give the reachable rung both sides of the actionable boundary - #146

Merged
patchstackdave merged 1 commit into
mainfrom
feature/ladder-exact-local-rung
Aug 19, 2026
Merged

Give the reachable rung both sides of the actionable boundary#146
patchstackdave merged 1 commit into
mainfrom
feature/ladder-exact-local-rung

Conversation

@patchstackdave

Copy link
Copy Markdown
Contributor

ENG-3622. Map side only — the platform fixtures and the reachable verdict assertion follow once
saas#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 reachable existed and passed. The one
app on it concatenates request input into its query:

db.query("SELECT * FROM items WHERE name = '" + req.query.name + "'")

The map reports that correctly as transformed-local, which is exactly the tier a rule generator refuses
to 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:

case shape flow
ladder/reachable-exact axios.get(req.body.target) — untransformed exact-local, rule-generatable, coordinate post.target
ladder/reachable-transformed input concatenated into SQL transformed-local, proven, not pinnable

The 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/reachable said neither thing, so the pair renames itself — which does break the platform's
reference to reachable.json by design, and that follow-up regenerates it.

axios because the sink has to be one the map models. My first candidate (systeminformation, command
injection) 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.actionableFlow separates a proven flow from an actionable one, so if the exact app ever drifts to
transformed 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.

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.
@coderbuds

coderbuds Bot commented Aug 19, 2026

Copy link
Copy Markdown

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

See how your team is trending →

@patchstackdave

Copy link
Copy Markdown
Contributor Author

/review

@patchstackdave
patchstackdave merged commit fed3bf8 into main Aug 19, 2026
6 checks passed
@patchstackdave
patchstackdave deleted the feature/ladder-exact-local-rung branch August 19, 2026 08:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants