feat(learning): the 8 base validators for the roadmap engine#59
Merged
Conversation
Implements the 7 remaining validator types (table_exists, redis_key_exists, mongo_collection_exists, edge_exists, lb_upstreams, port_denied, asg_replicas) alongside the existing container_running, so roadmap steps can check real Postgres/Redis/Mongo state, network connectivity and ASG replica counts, not just container liveness. Reuses existing infrastructure rather than duplicating it: DB validators go through containerProvider's exec* commands (same idiom as the explorers), edge_exists/port_denied reuse NetworkService's security-group rule expansion (now exposed publicly) instead of re-deriving connectivity, and asg_replicas/lb_upstreams read directly off ContainerInfo's asgId/isAsgInstance fields. A shared resolveRunningContainer/resolveSourceAndTarget helper keeps node targeting and pedagogical fail messages consistent across validators. Each validator ships with pass/fail/degraded-case unit tests, and the existing example roadmap already exercises 4 of them end to end.
Derssa
approved these changes
Jul 15, 2026
OthmaneZ05
added a commit
that referenced
this pull request
Jul 18, 2026
Implements the 7 remaining validator types (table_exists, redis_key_exists, mongo_collection_exists, edge_exists, lb_upstreams, port_denied, asg_replicas) alongside the existing container_running, so roadmap steps can check real Postgres/Redis/Mongo state, network connectivity and ASG replica counts, not just container liveness. Reuses existing infrastructure rather than duplicating it: DB validators go through containerProvider's exec* commands (same idiom as the explorers), edge_exists/port_denied reuse NetworkService's security-group rule expansion (now exposed publicly) instead of re-deriving connectivity, and asg_replicas/lb_upstreams read directly off ContainerInfo's asgId/isAsgInstance fields. A shared resolveRunningContainer/resolveSourceAndTarget helper keeps node targeting and pedagogical fail messages consistent across validators. Each validator ships with pass/fail/degraded-case unit tests, and the existing example roadmap already exercises 4 of them end to end.
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.
Summary of Changes
Implements the 7 remaining validator types for the learning/roadmap validation engine —
table_exists,redis_key_exists,mongo_collection_exists,edge_exists,lb_upstreams,port_denied,asg_replicas— alongside the existingcontainer_running. Roadmap steps can now check real Postgres/Redis/Mongo state, network connectivity, and ASG replica counts, not just container liveness.Design choices, in short:
table_exists,redis_key_exists,mongo_collection_exists) go throughcontainerProvider'sexecutePsqlCommand/executeRedisCommand/executeMongoCommand, using the same query idiom already used by the Postgres/Redis/Mongo explorers.edge_exists/port_deniedreuseNetworkService's security-group rule expansion (computeSemanticRules, now exposed publicly) instead of re-deriving connectivity from raw security groups — this is the same logic that drives real iptables enforcement, so a validator's verdict always matches what's actually applied.asg_replicas/lb_upstreamsread directly offContainerInfo.asgId/isAsgInstance, no new dependency needed.resolveRunningContainer/resolveSourceAndTargethelper keeps node targeting, type checks, and pedagogical fail messages (observed vs. expected, plain language, no raw Docker ids) consistent across all 7 validators.fail("still starting up, try again"), not an infrastructure error — only a genuinely unreachable Docker daemon propagates aserror.Types of Changes
Verification & Testing
Automated Checks
npm run lintsuccessfully with no errorsnpm run buildsuccessfully with no compilation errorsnpm testsuccessfully (all tests pass — 206 tests, 25 suites)Manual Verification
Ran the backend against real Docker and exercised
container_running,table_exists,edge_existsandport_deniedin both pass and fail against real containers, using the existing example roadmap (roadmaps/example-first-architecture.json), which already targets 4 of these 8 types:ubuntunode →container_runningflips fail → pass.CREATE TABLE users (...)through it →table_existsflips fail → pass, including the "database still starting up" pedagogical message before Postgres was ready.edge_existsflips fail → pass; widened the rule to all ports →port_deniedflips pass → fail, matching the real enforcement policy.Checklist