C#: no read/write direction on member usage, and no ORM (EF6/EF Core) entity→table mapping — "which code writes property X / table Y" cannot be answered #2894

Context. We index a large legacy .NET codebase (≈45k C# files, 64 solutions, mixed .NET Framework / ASP.NET Web Forms / EF6 / EF Core, ~1.9M nodes) with codebase-memory-mcp 0.11.0 (production) and 0.12.1 (trial). To know how far to trust the graph we built a Roslyn 5.9 reference (MSBuildWorkspace per solution, SemanticModel.GetSymbolInfo on every invocation / object creation) and compared edge by edge (key = caller file, call line ±1, target name; the engine's properties.line/strategy/confidence were used). Numbers below are from one sub-repo (8,458 files, 904,672 call sites, 310,119 with the target defined in the repo); the two larger sub-repos (≈1.4M and ≈2.6M call sites) show the same picture within a few points. Related: #2874 (INHERITS loss with constructors) and #2876 (maintainer C# gap list).

1. No read/write direction on member usage. "Which code writes property Order.Status?" is a daily question in a legacy codebase. USAGE edges do not distinguish assignment from read. Roslyn classifies 585,669 write accesses (assignment, +=, ++, out/ref, object initializer) across the largest sub-repo; we had to build a side table for it.

2. ORM entity → table mapping and ORM write/read classification. With EF6/EF Core, "which code writes table X" has no SQL text to match; the writers are DbSet<T>.Add/Remove, entity property assignment + SaveChanges, ExecuteUpdate/Delete. From Roslyn we extract the mapping (ToTable(...), [Table], DbSet<T> naming convention) and 31,775 classified accesses in the largest sub-repo; many tables have 10–37 ORM writers and zero SQL writers, so a text/SQL-based answer is simply "nobody writes it".

Suggestions. (a) An access property on USAGE (read | write | readwrite) or separate WRITES edges for fields/properties; (b) optional ORM extraction (EF Core / EF6 / NHibernate attributes and fluent mapping) producing MAPS_TO_TABLE (entity → table) and WRITES_TABLE / READS_TABLE edges from the call site. For .NET line-of-business code this is the single biggest gap for data-flow questions; the SQL-string side (which we also map) covers only the stored-procedure / inline-SQL half.

Reproduction / offer. Our comparison script (reads the engine's SQLite graph and a Roslyn-produced SQLite call map, reports recall/precision per strategy with the error classes above) and the Roslyn extractor are generic (.NET 8, Microsoft.CodeAnalysis 5.9). We can share both, and can run any candidate build against the same corpus and report the same tables.