Swift adapter story

Swift repositories deserve the same evidence contract.

Swift code often carries product behavior, mobile workflows, API calls, UI surfaces, package dependencies, and local data paths. TraceMap Swift v0 gives reviewers a static way to name those surfaces with rule IDs, evidence tiers, file spans, commit SHA, coverage labels, and limitations.

Public claim level: shipped. Proof: PR #425, merge commit e8813daaf763e277e7c5d88a2c0b2ad0b570f25a. This is the story layer for the Swift evidence lane; it does not replace the proof matrix.

Why this matters

Reviewers need evidence they can repeat without overstating it.

For managersSwift v0 turns adapter coverage into a readable claim: what static evidence exists, what proof anchors it, and what remains outside the claim.

For reviewersThe evidence lane gives review packets a shared vocabulary for Swift inventory, symbols, calls, surfaces, storage/data evidence, tiers, and reduced coverage.

For architectsSwift now fits the same cross-language evidence model as the rest of TraceMap instead of becoming a one-off mobile exception.

For engineersThe output can help inspect where supported Swift surfaces appear in a repository snapshot before runtime, test, or owner review takes over.

The proof shape

Swift v0 is not a prettier claim. It is a bounded evidence packet.

Inventory first

TraceMap can inventory supported Swift package/project surfaces, source files, module-ish metadata, and reduced-coverage labels. That is static repository evidence, not Xcode build proof or simulator execution.

Symbols and calls next

SwiftSyntax-backed declarations, call candidates, construction candidates, and direct relationships can be reported where syntax evidence supports them. The tier tells readers when the evidence is syntax-backed rather than compiler-resolved.

Surfaces stay labeled

HTTP/API client, SwiftUI/UIKit-ish, package/dependency, CoreData, UserDefaults, Keychain, SQLite, and Realm-style surfaces stay attached to rule IDs, evidence tiers, coverage labels, and limitations.

How to talk about it

Use Swift v0 to guide review, not to shortcut review.

Safe Swift story language keeps the proof path attached to the claim.
Question	Safe story answer	Where to verify	Boundary
Did Swift support land?	Swift v0 is shipped on `main` as deterministic static evidence coverage.	PR #425 and the Swift evidence lane.	Do not imply complete Swift understanding or runtime behavior.
What can teams do with it?	They can inspect supported static Swift surfaces and hand off proof, gaps, and limitations in a repeatable way.	Validation, limitations, and reduced coverage.	Do not present static surfaces as production traffic, release safety, endpoint performance, stored-value proof, or query execution proof.
Why does this help public copy?	The story keeps each Swift claim connected to rule IDs, evidence tiers, coverage labels, public claim level, and non-claims.	Site claim guardrails, static-vs-runtime boundaries, and proof source catalog.	Do not publish raw source snippets, raw SQL, secrets, local paths, raw remotes, credentials, stored values, private scan artifacts, or hidden validation details.

Evidence families

The adapter story points to the proof matrix instead of repeating every row.

static inventorySupported Swift package/project and source-file evidence with reduced-coverage labels.

symbols and callsDeclarations, call candidates, construction candidates, and relationships where syntax/static evidence supports them.

surface discoveryHTTP/API client, SwiftUI/UIKit-ish, package, dependency, and dynamic-composition gap evidence.

API-client walkthroughHow to read URLSession, URLRequest, Alamofire, and Moya-style static candidates without runtime network claims.

real-world smokePinned public Swift API-client samples and sanitized generated summaries for the shipped static evidence boundary.

storage/data surfacesCoreData metadata, UserDefaults keys, Keychain access patterns, SQLite text/shape evidence, and Realm model/property surfaces where supported.

evidence safetyRule IDs, evidence tiers, coverage labels, reduced-coverage gaps, and public-safe wording boundaries.

Non-claims

The Swift story stays static, deterministic, and evidence-backed.

TraceMap Swift v0 does not run Swift apps, simulators, devices, Xcode builds, SwiftPM restores, production traffic, or runtime persistence.
TraceMap Swift v0 does not prove runtime behavior, app navigation, rendered UI, complete navigation, user actions, production usage, endpoint performance, deployment state, release safety, stored values, query execution, live schema, Keychain item existence, or UserDefaults values.
TraceMap core scanning and reduction do not use AI impact analysis, LLM analysis, prompt-based classification, embeddings, or vector database analysis.
TraceMap should not describe a Swift surface as affected by a change unless reducer-backed public-safe evidence supports that wording.

Follow the evidence

Use the story to orient, then open the proof route.

Swift evidence lane Swift static inventory Swift symbols and calls Swift surface discovery Swift API-client evidence walkthrough Swift real-world smoke proof Swift storage and data surfaces Swift evidence safety Swift claim language checklist Capabilities Validation Limitations Reduced coverage Static vs runtime Site claim guardrails Proof source catalog Swift v0 PR #425