Four Enforcement Layers — Two of Them Block

This historical heading describes the reference adapter’s intended roles, not four installed controls or two unconditional guarantees. Actual blocking depends on registration, matched scope, commands and effective server settings.

Layer	Shipped scope	Limit
Post-edit lint check	Read-only checks on contained Python paths in the reference layout	Advisory; plain exit-0 output is debug-only
Session-end verification reminder	Diff-aware text naming example checks	Does not execute tests or prove model-visible delivery
Pre-push quality gate	Configured checks for an eligible standalone push from the installed root	Bounded parser; other clients/transports can bypass it
Required server checks/reviews	Effective branch policy applied to actual candidate evidence	Depends on contexts, visibility, scope and bypass rules

A workflow executes checks; server settings make their result a merge condition. A bot may post findings or emit checks depending on its integration. Verify the actual contract: a silent, skipped or stalled bot is not an approving one. Preserve each finding’s originally reviewed revision when assessing fixes.

Security scanning follows the threat model and applicable obligations, not only whether a project calls itself regulated. Approve source processing, credentials and any external upload. A scanner or AI auto-fix is not a compliance certificate.

Evidence boundary: offline fixtures test supplied script behaviour. They do not establish an adopter’s registration, model-visible feedback, server protections, application-test execution or production safety. Appendix E details the adapter limits.

---