Billing settings remain authenticated.
Before
Only authenticated users could access billing settings.
After this PR
Only authenticated users can still access billing settings.
Protected behavior preserved
Your code changed.
Did its behavior?
ShipCheck gives your repository memory of the behaviors it is supposed to preserve — then checks future changes against them.
Discover behaviorProtect behaviorTrack behavior historyCatch violations
app.shipcheck.dev/behaviors/ownership-protection
acme-inc/customer-portalBehavior Guard
ProtectedProtected behavior
Only the subscription owner may cancel a subscription.
ShipCheck remembers this expectation and checks future changes for evidence that the behavior was preserved, intentionally changed, or violated.
Protected since
April 18, 2025
Origin
82f3c91
fix: prevent cross-user subscription deletion
Evidence
4 files
Route, ownership helper, service, and regression test
Confidence
96%
Strong historical and implementation evidence
Behavior history
How this expectation evolved across repository history
Introduced
Ownership validation became part of the cancellation path.
Apr 18, 2025 · 82f3c91
Preserved
Billing refactor kept the ownership requirement intact.
Aug 22, 2025 · PR #294
Changed intentionally
Finance admins were intentionally granted cancellation access.
Jan 12, 2026 · PR #381
Violated
Current PR removes the ownership check from the route.
Sep 1, 2026 · PR #618
Git remembers what changed.
Not why the behavior mattered.
Important behavior gets buried in repository history.
A bug gets fixed. Authorization is tightened. A validation rule is added. A test captures an old production incident. Months later, the reason disappears from everyone's working memory.
ShipCheck makes that expectation persistent.
Important behavior becomes repository memory with evidence, history, origin, and future verification instead of being rediscovered every time a pull request changes the same system.
Your repository already has memory.
It just isn't explicit.
Important product decisions are scattered across tests, bug fixes, authorization checks, validation, helpers, and old commits. ShipCheck turns that implicit knowledge into persistent behavioral memory.
Behavior Guards
Turn important behavior into something the repository remembers.
A Behavior Guard is a persistent expectation about what the software must continue doing. Future changes are evaluated against that expectation instead of rediscovering it from scratch.
Repository knowledge that persists across pull requests
Behavior Guards
acme-inc/customer-portal
protected
Protected · 14 monthsOnly subscription owners may cancel subscriptions.
Protected behavior with implementation evidence, supporting tests, historical origin, and future violation tracking.
protected
Protected · 9 monthsDuplicate payment attempts must remain idempotent.
Protected after a previous payment regression introduced duplicate side effects.
protected
Protected · 6 monthsAdmin routes must reject non-admin users server-side.
The authorization guarantee remains protected even if frontend navigation changes.
A diff for behavior.
Not just lines.
A pull request changes code. ShipCheck maps that change back to the behavior the repository already understands so developers can see what actually changed before merging.
Behavioral diff
PR #618 · Refactor subscription cancellation
7 Preserved1 Changed1 Violated2 New
Checkout retry policy changed.
Before
Checkout attempts were retried up to 3 times.
After this PR
Checkout attempts are now retried up to 5 times.
Developer confirmed intentional
Subscription ownership protection removed.
Before
Only the subscription owner could cancel it.
After this PR
Any authenticated user can reach the cancellation operation.
Behavior Guard violated
Canceled subscriptions now emit an audit event.
Before
No cancellation-specific audit event existed.
After this PR
Successful cancellation emits subscription.canceled.
New behavior discovered
From implicit behavior
to repository memory.
The more ShipCheck is used, the more explicit context the repository can accumulate about what its software is actually supposed to do.
01
Discover behavior
ShipCheck identifies important safeguards, contracts, assumptions, and product behavior already encoded in the repository.
02
Protect what matters
Developers turn important expectations into Behavior Guards that persist beyond the pull request where they were discovered.
03
Evaluate future changes
Each pull request is compared against the repository's known behavioral expectations and supporting evidence.
04
Build the behavioral diff
ShipCheck identifies behaviors that were preserved, introduced, intentionally changed, or violated.
05
Update repository memory
Intentional changes update the expected behavior. Regressions remain violations until the protected behavior is restored.
Repository memory.
Inside the PR workflow.
When code changes, ShipCheck can compare the latest revision against protected behavior and report whether expectations were preserved, intentionally changed, or violated.
Behavior Guards persist beyond one review
Behavior history evolves with the repository
Re-check the latest revision with /shipcheck
github.com/acme/customer-portal/pull/618
sarah-devcommented now
/shipcheck
shipcheck-ai
botBehavioral verification completed.
Repository memorychecked
8
preserved
1
intentional
1
violated
Protected subscription ownership behavior is violated by the current revision.
Interactive example — no GitHub action is performed here.
Built around behavior.
Not review comments.
Pull-request analysis still matters, but it exists in service of a larger model: discovering, preserving, explaining, and evolving expected software behavior.
Behavior Discovery
Discover important behavior already encoded in tests, authorization logic, validation, schemas, callers, error handling, and existing safeguards.
Behavior Guards
Protect repository expectations so future pull requests can be evaluated against behavior the software is supposed to preserve.
Behavioral Diff
Describe meaningful pull-request changes as preserved, introduced, intentionally changed, or violated behavior.
Behavior History
Track when a behavior was introduced, preserved, intentionally changed, violated, restored, and preserved again.
Historical origin tracing
Mine git history across related implementation and test files to identify where a protected behavior originally became true.
Cross-file evidence
Connect behavior to implementation files, helpers, authentication boundaries, callers, tests, and other supporting repository evidence.
Regression protection
Turn a concrete behavioral violation into a focused regression test using the repository's existing framework and conventions.
Guarded repair
For supported findings, apply a bounded repair only when the pull-request revision still matches the version ShipCheck analyzed.
GitHub-native verification
Re-run ShipCheck after a fix and verify whether the protected behavior has actually been restored in the latest revision.
Don't just catch it once.
Make it harder to forget.
When ShipCheck finds a real behavioral regression, the workflow can continue into a guarded repair, a focused regression test, and a Behavior Guard that preserves the expectation for future changes.
violated
Subscription ownership behavior was violated
The protected behavior says that only the subscription owner may cancel it. This pull request removed the ownership validation while retaining only authentication.
Behavior Guard provides the expected outcome
Historical origin explains why the behavior exists
Supporting test and implementation files provide evidence
The current revision is compared against that evidence
The fix can be re-verified before merge
Generated from the violated behavior
The test proves that one authenticated user cannot cancel a subscription owned by another user.
Generated regression test
behavior-backeddescribe("subscription cancellation", () => {
it("rejects cancellation by a different user", async () => {
const owner = await createUser();
const attacker = await createUser();
const subscription = await createSubscription({
userId: owner.id,
});
const response = await cancelSubscriptionAs({
user: attacker,
subscriptionId: subscription.id,
});
expect(response.status).toBe(403);
expect(
await subscriptionStillActive(subscription.id),
).toBe(true);
});
});Code review can start over every PR.
Your software's expectations shouldn't.
ShipCheck is designed to sit alongside strong code-review tools rather than pretend they do not understand repositories. The difference is the primary object: ShipCheck maintains persistent expected software behavior and its history.
ShipCheck
Greptile
GitHub Copilot
Cursor Bugbot
CodeRabbit
Qodo
Primary object
Persistent software behavior
Behavior Guards represent expectations that persist across the lifetime of a repository.
Code review
AI agents review and test pull requests using broad codebase context.
Developer assistance + review
Copilot assists with coding and pull-request review across GitHub workflows.
Bug-focused PR review
Reviews pull requests for correctness, security, and logic issues.
AI code review
Automated review, summaries, walkthroughs, and configurable merge checks.
AI review + governance
Reviews changes against codebase context, requirements, and organizational rules.
Codebase context
Behavior + supporting evidence
Connects protected expectations to implementation code, tests, callers, safeguards, and history.
Full codebase graph
Builds graph-based context across repository files, dependencies, and related repositories.
Repository context
Uses repository code, instructions, and surrounding GitHub context during assistance and review.
Repository-aware
Uses project context while investigating pull-request changes.
Repository-aware
Uses codebase and pull-request context during automated review.
Codebase + organization context
Uses repository and organizational context to guide review.
Persistent behavior
First-class Behavior Guards
Expected software behavior is stored explicitly and evaluated again on future changes.
Rules + learned context
Persists review rules, team standards, and learned context for use in future reviews.
Persistent instructions
Repository, path-specific, and organizational instructions can guide future assistance and review.
Rules + learned context
Team and repository rules, including learned rules, can guide future reviews.
Rules + learnings
Review instructions, configuration, and learned team preferences can persist across reviews.
Rules + requirements
Organization and repository standards can persist and guide reviews across changes.
What persists over time
Behavior lifecycle
A protected behavior can be introduced, changed, violated, restored, or intentionally updated across commits and pull requests.
Review + context lifecycle
Reviews evolve as pull requests change while rules, feedback, and learned context inform future reviews.
Repository + PR lifecycle
Instructions can persist while commits and pull-request reviews evolve over time.
PR + rule lifecycle
Reviews update as pull requests change while repository and learned rules can persist across future reviews.
Incremental PR lifecycle
Updates review findings as new pull-request commits are pushed.
Rule + review lifecycle
Persistent standards and requirements can be evaluated as pull requests evolve.
Historical origin
Trace why behavior exists
Mines related code, tests, and git history to find the earliest supported introduction of a protected behavior.
Repository understanding
Indexes the codebase and uses repository, historical, and team context during review.
Repository + history context
Can use repository and GitHub context during assistance and review, without treating behavior origin as a dedicated product object.
Change-focused analysis
Primarily evaluates issues introduced by a pull request using repository and learned context.
Change-focused analysis
Primarily evaluates current pull-request changes using surrounding repository context.
Context-driven review
Uses relevant repository, requirements, and organizational context during review.
Intentional change
Update expected behavior
Developers can confirm a behavior changed intentionally so repository memory evolves with the product.
Feedback updates review
Team feedback, rules, and learned context can influence future reviews.
Update code + instructions
Developers can evolve repository code and persistent instructions as expectations change.
Resolve findings + update rules
Developers can resolve findings and update the rules that guide future reviews.
Resolve findings + update rules
Teams can resolve findings and change review rules, configuration, and preferences.
Update requirements + rules
Teams can evolve the organizational standards and requirements applied during review.
Testing
Violation → regression test
Generates a focused test from the specific protected behavior ShipCheck determined was violated.
Targeted test generation + execution
TREX generates and runs targeted tests and runtime checks against pull-request changes in a sandbox.
Test assistance
Copilot can help developers create, modify, and reason about tests.
Agent-assisted fixes
Findings can flow into Cursor agents that modify code and tests.
Test generation
Can generate unit tests for changed code.
Test-generation workflows
Provides AI-assisted test generation and testing workflows alongside code review.
Security
Behavior + deterministic checks
Security regressions can violate Behavior Guards while deterministic checks catch known high-signal patterns.
Static + AI security review
Combines deterministic scanning, dependency checks, and context-aware security analysis.
Security ecosystem
GitHub provides code scanning, dependency security, secret scanning, and code-review tooling.
Security findings
Can flag security issues introduced in pull requests.
Security review
Can surface security concerns during automated review.
Security + governance
Can evaluate security and organizational requirements during review.
Positioning comparison, not a benchmark. Competitor capabilities evolve over time and vary by plan, configuration, platform, and product surface. ShipCheck is not claiming that other tools lack repository context or bug detection.
Behavioral memory,
explained.
ShipCheck is built around one idea: important software behavior should not disappear just because the team moved on from the pull request that introduced it.
No. Code review is one input into ShipCheck, not the product model itself. ShipCheck maintains persistent behavioral memory for a repository. Important expectations can become Behavior Guards, gain historical origins and supporting evidence, and develop a lifecycle across future pull requests.
A Behavior Guard is an explicit expectation about something the repository is supposed to keep doing, such as rejecting expired sessions or preventing one user from modifying another user's resource. Future changes can then be evaluated against that expectation.
Repository rules usually describe how code should be written or reviewed. A Behavior Guard describes what the software must continue doing. ShipCheck also tracks where that behavior came from, what evidence supports it, and how it changes over time.
Not every behavior change is a regression. A developer can confirm an intentional change, allowing ShipCheck to update the expected behavior instead of continuing to treat the previous version as the correct one.
Yes. Pull requests are one of the main events ShipCheck uses to compare current code against repository memory. The difference is that the review starts from accumulated behavioral expectations rather than treating every pull request as an isolated event.
Important safeguards often exist because of old bugs, incidents, security fixes, or product decisions. ShipCheck preserves that context so future changes do not accidentally erase behavior the team previously decided mattered.