Local-only inputs
Operator-provided sample paths live under ignored local metadata. Public copy may use neutral labels only.
Legacy validation
Messy old repositories are where evidence discipline matters most.
TraceMap is preparing a validation pass for old and unusually large .NET codebases: projects that may not restore, may not build, may use legacy UI wiring, and still need honest static evidence instead of a clean-room demo story.
Public claim level: concept. The underlying validation spec remains hidden for public claims until a redacted validation summary exists. This page describes the validation plan, not completed legacy support results.
Why this matters
Legacy validation is not about making old code look clean.
Failed builds still have evidenceOld target frameworks, unsupported toolsets, missing SDKs, and broken project files should reduce coverage instead of turning the scan into a clean result.
Fallbacks must be labeledSyntax, config, package, SQL, and project evidence can still help reviewers, but it must carry the right evidence tier and limitation language.
UI entry points are trickyWinForms and WebForms event wiring may appear as semantic, structural, syntax, text, or missing evidence depending on what the scanner can actually observe.
Large repos test practicalityDuration, artifact size, fact counts, analyzer gaps, and truncation limits matter when the repository stops being a toy sample.
Validation dimensions
The planned pass measures behavior before claiming support.
Scan resilience
When old projects cannot load, validation should record reduced coverage and any available fallback evidence.
Environment clues
Old target frameworks, project styles, package files, and build-tool hints can be summarized as evidence-backed guidance.
UI event probes
WinForms and WebForms handler wiring should be checked without claiming runtime reachability or user behavior.
Large repository smoke
Validation should capture duration, artifact size, fact counts, coverage labels, and truncation or deferred status.
Redacted summaries
Only labels, counts, rule IDs, coverage labels, evidence tiers, and limitations can move toward public copy.
What stays hidden
The validation source can be real without making private details public.
local pathsOperator-only inputs remain under ignored local metadata and must not appear in committed files.raw scan artifactsSQLite indexes, fact streams, manifests, reports, and logs from private/local samples stay local-only.raw identityRepository remotes and private project names are replaced by neutral labels before public discussion.raw valuesSource snippets, SQL text, config values, connection strings, and secrets do not belong in site copy.uncleared summariesAny redacted summary candidate remains hidden until it passes the pre-publish safety checklist.Public-safe shape
When results exist, the site should show the summary, not the raw repository.
Sample labelsUse neutral labels such as legacy UI, large public client, or unknown legacy app instead of repository names.
CountsShow fact counts, artifact presence, elapsed time, output-size status, and analyzer gap counts.
Evidence vocabularyUse rule IDs, evidence tiers, coverage labels, source kinds, and limitations for every public conclusion.
Follow-up gapsIf event wiring is not captured, record a validation gap and propose a scanner or reporting follow-up instead of claiming absence.
Non-claims
This concept page does not upgrade hidden validation into a public result.
- It does not claim TraceMap already supports arbitrary legacy .NET codebases.
- It does not claim old UI event wiring proves runtime execution, user reachability, or downstream behavior.
- It does not publish local validation results, local paths, private repository names, raw remotes, source snippets, SQL, config values, or secrets.
- It does not replace a redacted validation summary with marketing copy.
Source material