{"schemaVersion":"2.0.0","locale":"en","title":"Incompatible registration or entry point","description":"Rule ID: architecture.registration-contract-mismatch@1.0.0. Availability below refers to source-scan at product 524fa07e.","htmlUrl":"https://docs.swift-analyzer.com/catalog/architecture.registration-contract-mismatch/","markdownUrl":"https://docs.swift-analyzer.com/catalog/architecture.registration-contract-mismatch/index.md","productRevision":"524fa07e0ae4153c84ac12ae9eb6559df89ec2be","catalogRevision":"4558458d","docsRevision":"1f17ba58ab08627e0de898f1442067b09e960b48cd5605d6529e9275f8930d68","channel":"pre-prod","maturity":"experimental","access":"owner-provided-checkout","markdown":"# Incompatible registration or entry point\n\nRule ID: architecture.registration-contract-mismatch@1.0.0. Availability below refers to source-scan at product 524fa07e.\n\n## V-ARCH-09 — Incompatible registration or entry point\n\nIncompatible registration or entry point. It examines repository-wide reachability, dependencies, resources, and API boundaries.\n\n### Availability\n\nNot available in source-scan. There is no source-scan flag to activate this condition.\n\n### Example and action\n\nIllustrative design scenario, not a runnable Swift example or a reproduced analyzer result. The stated availability and evidence boundaries still apply.\n\n**Before:** A shipping registration names a handler whose signature no longer matches the runtime entry-point contract.\n\nReview the following change against the contract and build variants described above.\n\n**After:** Update the registration and handler together, preserving the expected name, signature and lifetime. Exercise the actual registration path in each admitted shipping variant.\n\n### Intended analysis\n\nIntended reasoning: Model declarations, uses and entry points as a graph. A dependency or visibility decision needs the relevant consumers and build variants; an absence claim additionally needs a closed, complete graph. Required evidence: reachability, dependency, resource, and API-boundary facts\n\n### Assumptions and unknown\n\nThe relevant facts must be admitted for the selected immutable build world. Unknown aliases, external effects, unsupported source forms or incomplete consumers can prevent a conclusion. Availability in this workflow is stated above; the illustration does not expand that availability.\n\n### Evidence and interpretation\n\nThe target catalog describes the intended condition. It is not evidence of an active source-scan diagnostic.\n\nHistorical evidence at 4558458d: accepted-subset (a limited set of source forms and profiles passed historical checks). That evidence has not been requalified for this product revision.\n\n[How we validate checks](https://docs.swift-analyzer.com/concepts/validation/) explains the evidence boundary. [Foundations](https://docs.swift-analyzer.com/concepts/foundations/) separates method assumptions from implementation claims.\n","anchors":["incompatible-registration-or-entry-point","V-ARCH-09","availability","example-and-action","intended-analysis","assumptions-and-unknown","evidence-and-interpretation"]}