Follow one engineering decision from repository facts to a verified change boundary.
This is a committed demonstration artifact. It does not pretend to execute Vericore in the browser; every value is static, inspectable, and shaped around the current prepare → change → verify workflow.
THE LOOP
One change. One persisted boundary.
Start with repository facts, follow the impact, inspect the evidence, prepare the change, then verify the original contract after the agent edits code.
01Repositoryfacts
02Impactblast radius
03Evidencecitations
04Planbounded work
05Contractchange boundary
06Realitystate binding
SAMPLE REPOSITORY
payment-service
STATIC ARTIFACT
01 / REPOSITORYStart with deterministic structure.Vericore maps the codebase before higher-level reasoning begins.
428files in sample snapshot
1284relationships in sample snapshot
12knowledge hotspots in sample snapshot
controllerPaymentController
servicePaymentService
repositoryPaymentRepository
serviceFraudService
repositoryRiskRepository
testPaymentTests
The numbers above are demonstration data, not a claim about this repository. Real Vericore analysis is performed by the CLI/local application.
02 / IMPACTFollow the blast radius before editing.Dependency-aware impact turns a changed component into an explicit set of affected areas.
CHANGEDPaymentService
Potentially changes behaviour across the connected payment flow.
AFFECTED COMPONENTS
PaymentControllercaller contract
FraudServicedownstream dependency
PaymentTestsdirect test coverage
Risk signalReview contracts and affected tests before implementation.
Known uncertaintyRuntime gateway behaviour still requires integration verification.
03 / EVIDENCEEvery conclusion has a bounded source.Evidence makes repository reasoning inspectable instead of turning a model response into an unsupported claim.
Delegates payment creation to PaymentServicePaymentController.kt:28
direct
E34
Recent fraud-flow changes touched PaymentServicegit history
historical
The evidence view illustrates the traceability model; it is not a live query against a visitor's repository.
04 / PLANTurn evidence into bounded work.The planner is read-only: it proposes affected components, risks, implementation steps, and verification criteria before changes begin.
01
Inspect affected contracts
PaymentController and PaymentRepository
02
Update implementation
Keep FraudService boundary explicit
03
Update verification
Cover direct callers and impacted tests
04
Run integration verification
Confirm external gateway behaviour
05 / CONTRACTCross a persisted change boundary.Prepare records what was allowed to change and what must be verified later.
06 / REALITYKnow which repository state the evidence belongs to.Engineering Reality binds analysis and context to repository state so stale evidence can be rejected.
STATE BOUNDARYrealityDigest / deterministic
If repository state changes after analysis, Reality can reject the stale analysis instead of silently mixing states.
ANALYSISanalysis-snapshot.json
CONTEXTengineering-context.json
IDENTITYrealityDigest / deterministic
BOUND COMPONENTS
01repository HEAD
02analysis digest
03context digest
04repository-relative fingerprints
WHY STATIC?
Reproducible proof beats a fake live demo.
GitHub Pages hosts static assets. This explorer intentionally uses committed sample artifacts so visitors can inspect the verification workflow without sending repository data to a hidden backend.